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INTRODUCTION 


EXECUTIVE  SUMMARY 


The  Federal  Aviation  Administration  (FAA)  la  currently  in  the 
process  of  developing  a  new  computer  system,  called  the  Advanced 
Automation  System  (AAS),  to  help  control  the  nation's  air  traffic. 
The  AAS  will  consist  of  new  or  enhanced  hardware  (l.e.,  Central 
Processing  Units,  memories,  and  terminals)  and  new  software. 


The  new  software  will  retain  most  or  all  of  the  functions  In  the 
existing  NAS  (National  Airspace  System)  En  Route  Stage  A  software, 
but  recoded  and  possibly  using  different  algorithms.  In  addition, 
the  new  AAS  software  will  contain  several  new  functions  that  make 
greater  use  of  the  capabilities  of  automation  for  Air  Traffic 
Control  (ATC).  These  new  functions  will  represent  the  initial 
implementation  of  the  concept  known  as  AERA. 

When  fully  implemented,  the  AERA  functions  are  intended  to  detect 
and  resolve  many  routine  ATC  problems  automatically,  and  act  to 
implement  those  resolutions.  The  controller  will  not  need  to  be 
fully  Involved  with  such  routine  situations,  and  will  thus  have  a 
greater  capability  for  maintaining  an  overall  control  plan  and 
dealing  with  less  routine  problems.  The  result  is  planned  to  be  a 
significantly  enhanced  control  capability,  with  benefits  for 
airspace  users  and  Increased  levels  of  controller  productivity  and 
safety. 


The  AERA  functions  will  be  introduced  as  a  series  of  packages  to 
provide  a  staged  evolution  of  capability.  AERA  will  initially 
appear  to  the  controller  as  a  set  of  problem  detection  and  planning 
tools  to  help  move  traffic  more  effectively,  but  it  will  develop 
into  an  automated  resolution  and  decision-making  system.  Such  full 
automation  of  the  air  traffic  control  process  is  the  final  stage  to 
be  described  in  this  paper,  although  it  .  may  never  be  completely 
achieved. 


PURPOSE  AND  SCOPE 


There  are  three  principal  goals  for  providing  additional  automation 
assistance  to  the  air  traffic  controller: 

e  increasing  services  to  the  users 
e  Increasing  controller  productivity 
e  improving  system  safety 


These  benefits  are  to  be  obtained  through  the  Implementation  of  the 
AERA  concept.  The  highest  level  of  benefits  would  come  from  the 


highest  degree  of  automation,  but  the  FAA  recognises  that  a  com¬ 
pletely  automated  ATC  system  cannot  be  Implemented  Immediately. 
Aside  from  the  technical  challenges,  there  are  possible  problems  of 
safety,  controller  training,  and  controller  acceptance  If  the  ATC 
system  Is  automated  too  quickly. 

Consequently,  Implementation  of  the  AERA  functions  Is  planned  to 
occur  In  a  series  of  stages.  Each  stage  of  development,  or 
"package,”  would  provide  for  additional  automation  capability  in 
several  functional  areas,  in  a  manner  which  enhances  the 
capabilities  of  the  system  as  a  whole  and  forms  the  basis  for  the 
next  Incremental  package.  This  series  of  AERA  packages  was 
described  In  MITRE  report  WP-83W149,  "Evolution  of  Advanced  ATC 
Automation  Functions,"  which  presented  the  rationale  for  the 
particular  functions  and  enhancements  In  each  package. 

The  work  described  In  this  report  provides  additional  detail  for  the 
package  descriptions.  The  packages,  as  defined  In  WP-83W149 ,  were 
Investigated  with  special  attention  to: 

e  How  the  new  functions  and  enhancements  Interface  with  each 
other  and  with  other  functions  of  the  ATC  system. 

e  How  the  controller  will  be  affected  by  the  new  functions, 
and  how  they  can  be  used  to  control  traffic. 

The  functional  and  operational  descriptions,  respectively,  will  dis¬ 
cuss  the  results  In  these  areas. 

These  descriptions  are  not  Intended  to  be  a  blueprint  for  the  imple¬ 
mentation  of  these  functions.  This  material  Is,  rather,  a 
recommendation  for  a  line  of  development  to  follow.  The 
investigations  were  intended  to  disclose  areas  for  additional 
research  and  to  provide  a  framework  for  decision-making.  Changes  to 
these  descriptions  are  not  only  expected,  they  are  the  desired 
result  of  documenting  current  thinking. 

DESCRIPTION  OF  THE  AERA  PACKAGES 

A  simplified  overview  of  the  development  of  the  AERA  packages  is 
shown  in  Figure  A.  In  this  diagram,  each  vertical  column  represents 
a  separate  stage  of  automation;  enhancements  to  the  functional  areas 
are  arranged  horizontally  from  left  to  right. 

The  Initial  package  of  advanced  automation  features,  referred  to  as 
AERA  1.01,  will  be  Implemented  as  part  of  the  initial  Advanced 
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FIGURE  A 

OVERVIEW  OF  THE  AERA  PACKAGES 


Autonation  Systen  of  hardware  and  software.  AERA  1.01  will 
Introduce  autonated  planning  tools  which  use  the  aircraft  flight 
plan  data.  AERA  1.01  will  consist  of  four  functions: 

#  Trajectory  Estimation  will  calculate  the  flight  path  of  the 
aircraft  In  four  dimensions,  based  on  Information  from 
flight  plans  and  other  sources. 

e  Flight  Plan  Conflict  Probe  will  compare  aircraft  trajec¬ 
tories  In  order  to  test  for  conflicts  between  aircraft. 

#  Airspace  Probe  will  use  the  aircraft  trajectory  to  test  for 
conflicts  with  special  use  airspace  and  terrain. 

#  Sector  Workload  Probe  will  display  various  workload-related 
measures  to  supervisory  personnel. 

AERA  1.02  will  add  several  new  functions  and  will  integrate  the 
advanced  planning  functions  more  closely  with  the  existing 
functions.  A  Long  Range  Probe  capability  will  be  added  to  help  the 
controller  evaluate  off-airway  route  requests  which  extend  beyond 
the  prediction  horizon  of  the  Conflict  Probe.  The  Airspace  Probe 
will  be  enhanced  to  consider  conflicts  with  dynamic  weather  areas, 
as  well  as  with  static  areas  of  special  use  airspace.  Metering 
advisories  to  the  controller  will  be  checked  for  potential  conflicts 
before  being  displayed.  The  controller  will  be  able  to  make  more  of 
the  overall  control  plan  known  to  the  automation  system,  which  in 
turn  will  provide  reminders  of  planned  actions  at  the  appropriate 
times. 

In  AERA  2,  these  functions  will  be  enhanced  to  improve  controller 
productivity.  Three  steps  are  planned  for  AERA  2.  The  first,  AERA 
2.01,  will  introduce  a  computer  capability  for  helping  the 
controller  to  resolve  those  problems  detected  by  the  other  advanced 
automation  functions.  Initially,  this  capability  will  consist  of 
general  advisories  presented  to  the  controller,  with  the  controller 
adding  the  necessary  details.  In  AERA  2.02,  the  controller  will  be 
presented  with  several  specific,  complete  resolutions;  if  one  is 
selected,  it  will  be  automatically  converted  into  a  datallnked 
clearance  to  be  sent  to  the  aircraft  upon  approval.  In  AERA  2.03, 
only  a  single  resolution  is  displayed  to  the  controller.  If  the 
resolution  is  approved,  it  is  translated  into  a  clearance  which  is 
presented  to  the  controller  and  automatically  datallnked  to  the 
aircraft  unless  specifically  vetoed  by  the  controller.  The 
resolutions  and  reminders  are  assigned  priorities  by  the  system, 
based  upon  a  global  planning  perspective. 


Finally,  full  automation  is  applied  to  the  ATC  system  in  AERA  3, 
allowing  routine  planning  and  resolution  actions  to  be  conducted 
without  controller  intervention.  The  controller  is  then  left  free 
to  deal  with  special  situations. 

The  above  survey  of  the  AERA  packages  has  been  provided  in  order  to 
establish  a  sense  of  how  the  ATC  system  is  seen  to  develop  over  time 
with  the  Introduction  of  the  automated  functions,  and  how  the 
individual  packages  contribute  to  the  goal  of  full  ATC  automation. 
The  remainder  of  this  summary  presents  a  functional  and  operational 
overview  of  each  package. 

AERA  1.01 


The  first  package  of  AERA  functions  will  include: 

•  Trajectory  Estimation 

•  Flight  Plan  Conflict  Probe 

•  Airspace  Probe 

•  Sector  Workload  Probe 

These  functions  will  be  installed  in  the  AAS,  in  addition  to  the 
automated  functions  currently  available  in  NAS  Stage  A  and  the  other 
functions  which  will  be  implemented  in  the  "host*  computers  prior  to 
the  AAS,  such  as  En  Route  Metering  II  and  IFR/VFR  Conflict  Alert. 

Trajectory  Estimation  will  construct  a  four-dimensional  (x,y,z,t) 
description  of  the  planned  flight  path  of  each  controlled  aircraft 
within  the  planning  region  of  the  Area  Control  Facility  (ACF),  using 
information  from  the  filed  flight  plan,  stored  aircraft  performance 
data,  and  available  data  on  winds  and  temperatures  aloft.  When  sig¬ 
nificant  deviations  from  this  trajectory  are  detected,  it  will  be 
recomputed  in  a  way  which  attempts  to  compensate  for  the  errors  in 
the  input  data  ("resynchr  on  Nation").  Trajectories  will  also  be 
recomputed  to  reflect  flight  plan  amendment  messages  entered  by  the 
controller.  The  trajectory  should  always  represent  the  best  avail¬ 
able  estimate  of  the  future  position  of  the  aircraft.  The  control¬ 
ler's  compliance  in  following  good  current  control  practices,  in 
terms  of  entering  flight  plan  amendment  messages  when  new  clearances 
are  given  and  maintaining  conformity  between  the  aircraft  and  its 
cleared  route,  is  critical  to  the  accuracy  of  the  trajectories  and 
the  accuracy  of  the  other  planning  and  control  functions. 

Flight  Plan  Conflict  Probe  (FPCP)  compares  aircraft  trajectories  to 
detect  situations  in  which  the  required  separation  between  aircraft 
may  or  will  be  violated.  If  immediate  controller  action  is  not 
required  to  resolve  the  conflict,  it  is  termed  an  Advisory  Conflict, 
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and  the  controller  receives  an  advisory  message  from  the  probe.  If 
prompt  action  by  the  controller  is  deemed  necessary  to  avoid  a 
separation  violation,  a  Priority  Conflict  is  declared  and  the  con¬ 
troller  receives  a  priority  message.  The  advisory  and  priority 
messages  contain  sufficient  information  to  identify  the  conflict  for 
the  controller;  additional  information  may  be  available  in  the  form 
of  an  optional  graphic  situation  display.  FPCP  considers  the  entire 
valid  length  of  the  trajectory,  which  may  extend  across  the  entire 
ACF  Planning  Region.  Predicted  violations  are  not  necessarily 
displayed  immediately  to  the  controller;  the  message  is  presented  to 
the  controller  at  a  time  which  depends  on  such  factors  as  the  time 
of  separation  violation. 

The  Airspace  Probe  compares  Individual  aircraft  trajectories  against 
the  stored  data  base  of  special  use  airspace  and  terrain  protection 
regions  which  the  aircraft  may  not  be  allowed  to  penetrate.  The 
controller  will  be  notified  as  soon  as  an  airspace  violation  is 
predicted.  If  more  than  a  specified  (system  parameter)  time  exists 
before  the  violation,  an  advisory  message  will  be  received;  the 
controller  can  then  inform  the  pilot  involved  so  that  the  pilot  can 
replan  the  route  or  obtain  authorization  to  enter  the  airspace.  If 
less  than  a  specified  time,  the  controller  will  direct  the  aircraft 
to  avoid  the  airspace  region. 

Both  Flight  Plan  Conflict  Probe  and  Airspace  Probe  will  be  invoked 
automatically  whenever  a  new  trajectory  is  added  or  an  existing 
trajectory  is  modified  or  automatically  updated.  These  functions 
may  also  be  invoked  by  a  controller  request  to  test  a  proposed 
flight  plan  amendment  for  conflicts,  as  part  of  the  Trial  Plan  Probe 
capability. 

Sector  Workload  Probe  uses  the  aircraft  trajectories  and  the  results 
generated  by  FPCP  and  the  Airspace  Probe  to  derive  several  workload- 
related  measures.  These  measures  are  then  used  by  the  Area  Super¬ 
visor  or  Area  Manager  to  assist  in  various  decisions  on  staffing  and 
hectorlsation  (combining  and  decombining  sectors).  The  supervisor 
will  be  able  to  specify  the  measures  to  be  displayed,  the  level  of 
detail,  the  geographic  and  time  region  to  be  considered,  and  the 
trigger  for  displaying  the  information:  on  demand,  periodically,  or 
when  a  preset  threshold  is  violated. 

AERA  1.02 


This  package  adds  some  new  automation  functions  to  those  introduced 
in  AERA  1.01  and  Integrates  the  automation  functions  more  closely. 
The  following  functions  are  new  to  AERA  1.02: 
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•  Long  Range  Probe 
e  Conflict-Free  Metering 
e  Dynamic  Airspace  Probe 
e  Controller  Reminders 

In  addition,  capabilities  will  be  added  to  transmit  text  messages 
entered  by  the  controller  to  da talink -equipped  aircraft,  to  utilise 
aircraft  performance  data  automatically  downlinked  by  da talink - 
equipped  aircraft,  and  to  detect  deviations  from  the  aircraft's 
cleared  speed.  The  functions  Introduced  in  AERA  1.01  and  previously 
will  also  be  modified  to  Improve  system  performance. 

The  Long  Range  Probe  (LRP)  is  an  aid  to  the  controller  for  determin¬ 
ing  if  possible  control  problems  may  exist  beyond  the  range  of  the 
Flight  Plan  Conflict  Probe.  In  AERA  1.02,  LRP  will  be  Invoked  auto¬ 
matically  when  an  off-alrway  route  is  first  requested,  and  possibly 
at  other  appropriate  times. 

LRP  Is  expected  to  help  the  ATC  system  accept  more  off-airway 
User-Preferred  Routes  (UPRs),  by  providing  the  controller  with 
information  about  areas  of  high  traffic  density  which  might  affect 
the  UPR,  as  well  as  facilitating  the  efficient  application  of 
ATC-pref erred  routes.  The  process  for  accomplishing  this  may 
Involve  the  designation,  by  appropriate  supervisory  personnel,  of 
"protected  airspace"  around  busy  traffic  flows  which  would  be 
avoided  by  the  UPR.  Automation  aids  also  may  be  Introduced  to  help 
establish  and  implement  "preferred  routes"  to  avoid  the  high-density 
areas.  Enhanced  versions  of  this  function  in  later  AERA  packages 
are  expected  to  be  more  dynamic,  presenting  information  to  the 
sector  controller  for  evaluation  or  automatically  determining  If  a 
UPR  is  acceptable,  on  a  case-by-case  basis.  Much  research  will  be 
required  to  determine  the  form  and  characteristics  of  the  Long  Range 
Probe  for  AERA  1.02  and  beyond. 

AERA  1.02  will  also  include  an  enhanced  version  of  the  Airspace 
Probe  introduced  in  AERA  1.01.  The  enhancement  will  consist  of  the 
capability  to  detect  encounters  between  an  aircraft  trajectory  and  a 
moving  region  of  airspace,  such  as  an  area  of  hazardous  weather. 
Information  on  the  dynamic  airspace  region  will  be  provided  by  a 
source  external  to  AERA  (e.g..  Center  Weather  Service  Unit  or 
Central  Weather  Processor). 

The  output  of  the  Dynamic  Airspace  Probe  will  be  a  message  to  the 
controller  containing  information  about  the  predicted  encounter. 
The  controller  will  then  inform  the  pilot  and  be  prepared  to  assist 
the  pilot  to  avoid  the  hazardous  area.  Controller  responsibilities 
would  be  unchanged  from  the  current  ATC  system,  although  more  infor¬ 
mation  on  the  weather  area  would  be  available. 
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Conflict-Free  Metering  will  be  provided  in  AERA  1.02  by  integrating 
the  metering  function  (introduced  prior  to  the  AAS)  with  the  AERA 
conflict  probe  functions.  Metering  advisories  will  be  checked  by 
the  probes  for  conflicts  before  the  advisory  is  displayed  to  the 

controller  and,  if  a  conflict  is  detected,  the  advisory  will  be 
modified  as  appropriate. 

The  metering  advisories  presented  to  the  controller  will  be 

conflict-free  only  within  the  limits  of  the  probes;  that  is,  the 

controller  will  still  need  to  monitor  for  conflicts  with  VFR  air¬ 
craft  or  with  aircraft  that  are  not  in  conformance  with  their 
trajectories.  A  conflict  may  also  exist  beyond  the  time  horizon  of 
the  probe.  Lastly,  the  metering  advisory  cannot  be  guaranteed  to  be 
conflict-free  beyond  the  metering  fix,  since  the  goal  of  the 

metering  advisory  (delivering  the  aircraft  to  the  metering  fix  at  a 
specific  time)  will  not  be  changed. 

The  Metering  Planning  function  in  AERA  1.02  may  also  allow  the 

controller  to  request  an  alternative  advisory  if  the  one  displayed 
is  unacceptable.  The  controller  may  be  able  to  request  a  specific 
type  of  maneuver,  such  as  a  metering  vector,  or  may  simply  request 
the  "next  best”  alternative. 

The  last  major  new  feature  of  AERA  1.02  is  the  provision  of  Con¬ 
troller  Reminder  messages.  These  are  similar  in  purpose  to  the 
metering  advisory  messages  in  that  they  inform  the  controller  of  a 
clearance  which  should  be  delivered  to  the  aircraft.  The  aim  of 
this  capability  is  to  help  maintain  the  reliability  of  the  aircraft 
trajectories,  by  first  giving  the  controller  a  means  for  inserting 
planned  control  actions  into  the  trajectory  and  by  then  providing 
reminders  at  the  appropriate  time  to  perform  that  control  action. 

The  initial  implementation  of  Controller  Reminder  messages  is  to  be 
limited  to  altitude  transitions  only.  These  planned  transitions  may 
be  derived  from  the  flight  plan  according  to  routine  procedures  and 
Letters  of  Agreement,  or  they  may  be  generated  directly  by  the 
controller.  The  reminder  messages  may  be  inhibited  in  cases  where 
they  would  not  be  helpful,  such  as  for  standard  descents  into  a 
major  airport.  Upon  receipt  of  a  reminder  message,  the  controller 
will  normally  deliver  the  planned  clearance,  but  will  also  be  free 
to  change  the  clearance  as  appropriate. 

In  order  to  process  the  planned  actions  and  reminder  messages,  and 
monitor  aircraft  conformance  to  the  intended  maneuver,  AERA  1.02 
introduces  a  functional  component  termed  Tactical  Execution.  The 
Tactical  Execution  function  is  notified  when  the  activation  point 
for  a  planned  action  is  reached;  it  then  notifies  the  controller. 
If  the  controller  implements  the  planned  action,  Tactical  Execution 
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cacm i tors  the  maneuver  sad  alerts  the  controller  to  any  significant 
deviations  detected  (such  as  an  actual  descent  gradient  which  would 
put  the  aircraft  outside  the  altitude  band  protected  by  Flight  Plan 
Conflict  Probe). 

AERA  2.01 

In  addition  to  qualitative  improvements  to  the  previously  introduced 
functions,  AERA  2.01  includes  the  capability  to  present  general 
resolutions  to  the  controller  for  problems  detected  by  the  automated 
probe  functions.  The  Metering  Planning  function  is  also  enhanced  to 
allow  the  controller  to  approve  the  entire  metering  plan  for  an 
aircraft,  rather  than  only  individual  advisories  as  they  occur. 

The  general  resolution  advisory  provided  in  AERA  2.01  consist-*'  of  an 
aircraft  ID  and  the  general  maneuvers  which  can  be  perf  ed  to 
resolve  a  specified  conflict.  The  specific  parameter!  of  the 
maneuver  will  be  filled  in  by  the  controller.  The  <  <letely 
specified  maneuver  may  then  be  submitted  to  the  Trial  Plan  ->be,  to 
verify  that  it  does  Indeed  resolve  the  conflict  without  cr  Ing  any 
new  ones. 

The  resolution  may  be  only  partially  specified;  for  example,  a 
vector  to  parallel  an  airway  at  a  specific  offset  might  not  include 
a  s tar t-of -maneuver  point  or  a  point  to  turn  back  to  the  airway. 
The  Trajectory  Estimation  component  will  be  enhanced  to  allow 
processing  such  planned  actions  where  the  goal  is  known,  but  not  the 
details  of  the  maneuver  to  achieve  that  goal.  Reminder  messages 
will  be  displayed  to  the  controller  by  the  Tactical  Execution 
function  at  the  appropriate  time  to  implement  the  planned  resolution. 

The  complete  metering  plan  for  an  aircraft  may  also  be  displayed  to 
the  controller  for  approval.  In  En  Route  Metering  II  (ERM  II), 
advisories  are  presented  singly,  but  they  are  designed  to  absorb 
only  a  portion  of  the  necessary  delay,  with  later  maneuvers  expected 
to  absorb  the  remainder.  It  is  expected  that  by  this  stage  of  the 
automation  development,  the  effect  of  a  metering  advisory  will  be 
predicted  accurately  enough  that  the  later  advisories  can  be  planned 
at  the  same  time. 

Controller  approval  of  the  metering  plan  will  allow  the  metering 
maneuvers  to  be  incorporated  into  the  aircraft's  trajectory  as  the 
best  estimate  of  the  actual  path  of  the  aircraft.  In  AERA  2.01, 
incorporating  the  maneuvers  before  the  clearance  is  delivered  to  the 
aircraft  may  present  some  operational  problems,  but  it  is  expected 
in  moat  cases  to  result  in  more  accurate  trajectories  and  better 
conflict  predictions. 


The  controller  will  then  be  notified,  at  the  appropriate  time,  of 
the  next  metering  maneuver  for  the  aircraft.  Prior  approval  of  the 
metering  plan  will  not  prevent  the  controller  from  modifying  the 
plan  later,  as  needed,  nor  will  it  mean  that  the  advisories  them¬ 
selves  would  not  be  changed  later  (to  avoid  a  newly  developed 
conflict,  for  instance).  Such  changes  would  need  to  be  reflected  in 
the  trajectory  as  soon  as  possible,  however. 

AERA  2.02 


The  Conflict  Resolution  Planning  function  introduced  in  AERA  2.01  is 
enhanced  in  the  next  stage  to  provide  the  controller  with  a  set  of 
several  specific  resolution  alternatives,  rather  than  a  single 
general  resolution.  Each  specific  advisory  contains  sufficient 
information  to  formulate  the  appropriate  clearance  for  the  aircraft 
involved. 

If  the  controller  accepts  one  of  the  suggested  resolutions  (rather 
than  independently  generating  a  resolution) ,  the  accepted  resolution 
will  be  translated  into  a  correct  clearance  and  transmitted  by  data- 
link  to  the  aircraft,  if  it  is  properly  equipped.  The  clearance 
will  be  displayed  to  the  controller  first,  however,  and  will  not  be 
transmitted  until  approved. 

Other  functions  introduced  in  previous  AERA  packages  will  also  be 
enhanced  in  this  stage.  Most  significantly,  the  Long  Range  Probe 
function  is  expected  to  have  evolved  by  this  stage  into  a  fully 
automated  decision  tool  for  the  controller.  Data  on  expected  and 
historical  traffic  flows  will  be  evaluated  by  the  automation  in 
order  to  inform  the  controller  of  any  anticipated  control  problems 
beyond  the  range  of  the  Flight  Plan  Conflict  Probe. 

It  is  also  expected  that  in  this  stage  of  AERA  development  the 
metering  plan  will  be  incorporated  into  tee  trajectory  when  it  is 
generated,  without  requiring  specific  approval  from  the  controller. 

By  AERA  2.02,  the  Conflict  Alert  function  will  also  be  enhanced  to 
consider  more  information  from  the  aircraft's  flight  plan  and 
trajectory  than  it  does  in  the  present  ATC  system.  Because  only 
radar  track  data  is  considered  today,  NAS  Conflict  Alert  does  not 
know  about  planned  turns,  and  must  assume  that  the  aircraft  will 
maintain  its  current  heading;  this  leads  to  false  alarms  and  delayed 
detections  when  one  or  both  aircraft  are  turning. 

An  enhanced  Conflict  Alert,  called  the  Separation  Assurance  Monitor¬ 
ing  function,  will  use  trajectory  information  to  modify  the  track 
data  to  reflect  expected  turns  or  altitude  changes.  Separation 
Assurance  Monitoring  will  present  two  different  alert  messages  to  the 
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controller:  a  high-level  alert,  If  the  track  data  aa  modified  by 
the  trajectory  lndlcatea  a  conflict,  or  a  low-level  alert,  if  only 
the  track  data  lndlcatea  a  conflict.  The  latter  case  would  Indicate 
to  the  controller  a  situation  which  was  not  expected  to  present  a 
conflict,  but  which  could  lead  to  a  separation  violation  If  the 
aircraft  did  not  follow  their  expected  trajectories. 

ABBA  2.03 

This  ABBA  package  represents  the  last  stage  before  AERA  3.  Conse¬ 
quently,  the  ATC  functions  which  will  be  fully  automated  In  AERA  3 
will  all  be  present  In  AERA  2.03,  but  with  the  human  controller 
still  making  the  final  decision  In  each  case. 

This  characteristic  of  AERA  2.03  Is  reflected  In  each  functional 
area.  Only  one  specific  resolution  advisory  Is  presented  to  the 
controller,  representing  the  best  course  of  action  that  the  software 
could  determine.  Upon  approval  by  the  controller,  the  resolution  Is 
transmitted  as  a  clearance  to  the  properly-equipped  aircraft.  Data- 
llnk  transmission  occurs  In  veto  mode:  unless  the  controller  takes 
specific  action  to  expedite,  hold,  or  cancel  the  clearance.  It  will 
be  transmitted  a  specified  time  after  being  displayed. 

The  planning  functions  of  AERA  are  fully  Integrated  by  this  stage, 
so  that  the  resolution  advisories  presented  may  address  multiple 
control  problems  at  the  same  time.  For  example,  a  conflict  reaolu- 
tlon  maneuver  may  help  to  resolve  more  than  one  conflict,  or  may 
Incorporate  metering  goals  as  well. 

Deviations  from  the  planned  maneuvers,  and  deviations  from  the 
expected  trajectories,  were  detected  in  previous  AERA  packages  and 
displayed  to  the  controller.  In  AERA  2.03,  resolutions  for  these 
deviations  are  generated  and  displayed  for  controller  approval.  The 
resolutions  nay  take  the  form  of  new  clearances  for  the  aircraft  or 
amendments  to  the  aircraft’s  flight  plan  as  needed  to  restore  agree¬ 
ment  between  the  aircraft's  actual  and  expected  performance. 

AERA  3 

AERA  3  represents  the  goal  for  the  effort  to  automate  en  route  Air 
Traffic  Control.  In  this  stage  of  development,  the  automation 
functions  are  expected  to  detect  and  resolve  many  routine  ATC 
problems  automatically,  and  act  to  implement  those  resolutions.  The 
controller  will  not  need  to  be  fully  involved  with  such  routine 
situations,  but  will  have  a  greater  capability  for  maintaining  an 
overall  control  plan  and  dealing  with  less  routine  problems. 


xii 


In  most  cases,  the  specific  controller  approval  required  in  AERA 
2.03  will  no  longer  be  necessary.  The  controller  will*  however* 
have  the  option  to  Intercede  at  any  time.  The  controller  will 
receive  prior  notification  of  control  actions  which  are  planned  by 
the  autoaatlon*  as  feasible*  and  will  be  able  to  request  additional 
detailed  information  if  desired.  Actions  planned  by  the  automation 
system  may  be  modified  or  cancelled,  and  the  planning  tools  will 
exist  to  help  the  controller  to  investigate  alternative  actions. 

Although  the  controller  still  has  the  ultimate  responsibility*  it  is 
anticipated  that  the  resolutions  generated  by  the  system  will  be 
implemented  in  most  cases.  Consequently*  the  maneuvers  generated 
for  conflict  resolution  or  for  deviation  correction  will  be  incor¬ 
porated  into  the  trajectory  as  they  are  generated,  to  keep  the 
trajectory  as  current  as  possible. 

CONCLUSION 

This  report  presents  a  series  of  descriptions  of  the  AERA  packages 
as  currently  envisioned.  Both  operational  and  functional  character¬ 
istics  are  discussed:  what  the  functions  are  Intended  to  do*  and 
how  they  are  expected  to  interact  with  the  controller  and  other  ATC 
functions . 

This  document  is  not  intended  to  be  a  formal  description  of  a  fully 
developed  system.  There  are  many  unresolved  Issues  remaining*  and 
much  research  and  analysis  to  be  done.  Nevertheless*  the 
publication  of  this  material  is  appropriate  at  this  time  to  document 
the  current  design  of  AERA,  to  provide  information  useful  to  the 
design  of  the  AAS*  and  to  stimulate  discussion.  Revisions  to  these 
descriptions  are  certain  as  the  development  of  AERA  continues. 
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1.  INTRODUCTION 


The  Pederal  Aviation  Administration  (FAA)  la  currently  in  the 
process  of  developing  a  new  computer  system,  called  the  Advanced 
Automation  System  (AAS),  to  help  control  the  nation's  air  traf¬ 
fic.  The  AAS  will  consist  of  new  or  enhanced  hardware  (i.e., 
Central  Processing  Units,  memories,  and  terminals)  and  new  soft¬ 
ware. 

The  new  software  will  retain  most  or  all  of  the  functions  in  the 
existing  NAS  (National  Airspace  System)  En  Route  Stage  A  soft¬ 
ware,  but  recoded  and  possibly  using  different  algorithms.  In 
addition,  the  new  AAS  software  will  contain  several  new  func¬ 
tions  that  make  greater  use  of  the  capabilities  of  automation 
for  Air  Traffic  Control  (ATC).  These  new  functions  will  repre¬ 
sent  the  initial  implementation  of  the  concept  known  as  AERA. 

1.1  Evolution  of  ATC  Automation 


AERA  is  an  integral  part  of  the  FAA 'a  overall  twenty-year  plan 
for  improvements  to  the  nation's  air  traffic  control  system. 
This  plan,  as  set  forth  in  the  National  Airspace  System  Plan 
[1],  calls  for  enhancements  and  upgrades  to  the  en  route  and 
terminal  control  systems;  flight  services;  and  navigation, 
communication,  and  surveillance  systems. 

Replacement  of  the  computers  currently  used  for  air  traffic 
control  is  one  of  the  early  features  of  the  NAS  Plan.  New 
"host"  computers  will  be  installed  which  will  support  the  exist¬ 
ing  NAS  Stage  A  software  with  minimal  changes.  Additionally, 
the  improved  speed  and  capacity  of  the  host  computers  will  allow 
the  implementation  of  several  software  functions  currently  under 
development,  such  as  Conflict  Resolution  Advisories  and  En  Route 
Metering  II. 

After  the  host  computers  are  installed,  new  work  stations  for 
controllers  and  supervisors,  known  as  Sector  Suites,  will  be 
Introduced  .In  the  field.  In  addition  to  providing  the  control¬ 
ler  with  a  larger  and  improved  display  of  the  traffic  situation, 
the  Sector  Suites  will  include  interactive  displays  for  data 
entry  and  electronic  presentation  of  flight  data  currently 
printed  on  paper  flight  strips. 

The  new  hardware  of  the  AAS  will  then  be  installed,  either  as  a 
replacement  or  an  extension  of  the  host  computers.  The  new  AAS 
software,  incorporating  the  first  AERA  functions,  will  be  an 
integral  part  of  the  AAS  implementation. 


When  fully  implemented,  the  AERA  functions  are  intended  to 
detect  and  resolve  many  routine  ATC  problems  automatically!  and 
act  to  implement  those  resolutions.  It  is  expected  that  the 
controller  will  need  not  be  fully  involved  with  such  routine 
situations!  and  will  thus  have  a  greater  capability  for  main¬ 
taining  an  overall  control  plan  and  dealing  with  less  routine 
problems.  The  result  is  planned  to  be  a  significantly  enhanced 
control  capability,  with  benefits  for  airspace  users  and  in¬ 
creased  levels  of  controller  productivity  and  safety. 

The  AERA  functions  will  be  introduced  as  a  series  of  packages  to 
provide  a  staged  evolution  of  capability.  The  problem  detec¬ 
tion  functions  are  to  be  implemented  first,  to  provide  benefits 
to  the  airspace  users,  followed  by  the  resolution  functions  for 
enhanced  controller  productivity.  AERA  will  initially  appear  to 
the  controller  as  a  set  of  planning  tools  to  help  move  traffic 
more  effectively,  but  it  will  develop  into  an  automated 
decision-making  system.  While  such  full  automation  of  the  air 
traffic  control  process  may  never  occur,  it  is  the  goal  to  be 
described  in  this  paper. 

1.2  Benefits  of  Advanced  ATC  Automation 


There  are  three  principal  benefits  to  be  attained  by  providing 
additional  automation  assistance  to  the  air  traffic  controller: 

•  increased  services  to  the  users 

•  increased  controller  productivity 

•  improved  system  safety 

The  present-day  ATC  system  contains  examples  of  procedural 
restrictions  which  are  necessary  for  the  controller  to  be  able 
to  handle  the  existing  traffic  levels  safely,  but  which  impose 
constraints  on  the  aircraft  and  pilots  who  use  the  system. 
These  restrictions  tend  to  regularize  the  flow  of  traffic  and 
limit  variations  between  aircraft  to  acceptable  levels.  The 
proper  automation  functions  could  greatly  reduce  the  need  for 
restrictions  and  Increase  the  flexibility  of  the  air  traffic 
control  system  to  accommodate  the  desires  of  the  airspace  users. 
For  example,  it  might  be  less  important  for  all  aircraft  to  fly 
on  the  known,  published  routes  if  automation  aids  were  available 
to  provide  timely  detection  of  conflicts  between  any  two  air¬ 
craft,  on  published  routes  or  not. 

These  procedural  restrictions  tend  to  reduce  the  capacity  of  the 
airspace.  A  goal  of  the  AERA  automation  features  is  to  enable 
controllers  to  handle  additional  traffic  by  employing  automation 
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functions ,  rather  than  procedural  restrictions,  to  deal  with 
traffic  conflicts. 

This  Is  the  second  benefit  of  additional  ATC  automation: 
increased  controller  productivity*  Increased  controller 
productivity  can  be  achieved  through  any  of  the  following 
changes.  The  number  of  aircraft  per  sector  could  be  increased, 
the  size  of  the  sector  could  be  increased,  or  the  number  of 
controllers  per  sector  team  could  be  decreased. 

The  automated  functions  can  increase  controller  productivity  by 
making  the  control  task  easier  and  by  reducing  the  need  for 
involvement  in  certain  control  tasks.  Controller  workload  for  a 
given  traffic  level  is  expected  to  be  reduced  by  providing  more 
planning  assistance  to  the  controller,  thereby  dllowing  a 
structured  and  more  uniform  level  of  workload  for  the  controller. 

Certain  controller  tasks  can  also  be  eliminated  or  eased  consid¬ 
erably  by  automation.  For  example,  much  verbal  coordination 
between  controllers  was  eliminated  by  the  "silent  handoffs"  in 
NAS,  whereby  handoffs  between  sectors  were  initiated  automat¬ 
ically  and  conducted  by  use  of  simple  accept /acknowledge  push¬ 
button  actions.  Similarly,  it  is  expected  that  the  new  automa¬ 
tion  functions  of  AERA  can  further  improve  verbal  coordination 
between  controllers.  For  example,  verbal  discussion  of  a 
problem  could  be  supplemented  by  information  on  the  problem 
which  la  available  from  the  automation  and  sent  automatically 
between  controllers.  Other  coordination  is  required  today  to 
detect  potential  problems  in  the  other  controller's  sector, 
which  nay  be  done  more  efficiently  by  the  automated  probe 
functions. 

Lastly,  but  most  importantly,  additional  ATC  automation  is 
expected  to  make  beneficial  contributions  to  the  safety  of  the 
air  traffic  control  system.  By  improving  the  ability  of  the 
controller  to  monitor  traffic  and  detect  potential  problems  and 
by  providing  additional  planning  capability,  the  new  automation 
functions  are  expected  to  reduce  the  frequency  of  separation 
violations  between  aircraft  and  between  aircraft  and  terrain. 
The  reduced  need  for  coordination  between  controllers  also 
reduces  the  possibility  of  poor  communication,  one  of  the  main 
causes  of  operational  errors  in  the  ATC  System  (see  Appendix  G 
of  "The  Human  Element  in  Air  Traffic  Control:  Factors  in  System 
Recovery  and  Revitalization"  [2].) 


These  benefits  of  advanced  ATC  automation  are  to  be  obtained 
through  the  implementation  of  the  AERA  concept.  The  highest 
level  of  benefits  would  come  from  the  highest  degree  of  automa¬ 
tion,  but  the  FAA  recognizes  that  a  completely  automated  ATC 
system  cannot  be  implemented  immediately.  Aside  from  the  tech¬ 
nical  challenges,  there  are  possible  problems  of  safety,  control¬ 
ler  training,  and  controller  acceptance  if  the  ATC  system  is 
automated  too  quickly. 

Consequently,  implementation  of  the  AERA  functions  is  planned  to 
occur  in  a  series  of  stages.  Each  stage  of  development,  or 
" package”  of  features,  would  provide  for  additional  automation 
capability  in  several  functional  areas  in  a  manner  which 
enhances  the  capabilities  of  the  system  as  a  whole.  This  series 
of  AERA  packages  was  described  in  the  MITRE  report  "Evolution  of 
Advanced  ATC  Automation  Functions'*  [3],  which  presented  the 
rationale  for  the  particular  functions  and  enhancements  in  each 
package • 

The  work  described  in  this  report  provides  additional  detail  for 
the  package  descriptions  in  that  report.  The  AERA  packages,  as 
defined  in  the  MITRE  report,  were  investigated  with  special 
attention  to: 

•  How  the  new  functions  and  enhancements  interface  with 

each  other  and  with  other  functions  of  the  ATC  system. 

•  How  the  controller  will  be  affected  by  the  new  func¬ 

tions,  and  how  they  can  be  used  to  control  traffic. 

The  functional  and  operational  descriptions,  respectively,  will 
discuss  the  results  in  these  areas. 

These  descriptions  are  not  Intended  to  be  a  blueprint  for  the 
implementation  of  these  functions.  This  material  is,  rather,  a 
recommendation  for  a  line  of  development  to  follow.  The 

investigations  were  intended  to  disclose  areas  for  additional 

research,  and  to  provide  a  framework  for  decision-making. 
Changes  to  these  descriptions  are  not  only  expected,  they  are 
the  desired  result  of  documenting  current  thinking  in  this  area. 

1.4  Structure  of  This  Document 

Before  the  functional  and  operational  descriptions  of  the  AERA 
packages  are  presented,  an  overview  of  the  process  of  AERA 
evolution  is  presented  in  Section  2.  The  reasons  for  an 


evolutionary  approach  to  AERA  are  discussed  briefly,  followed  by 
the  guideline*  which  were  uaed  to  derive  the  « pacific  character¬ 
istic*  of  the  AERA  package*.  An  overview  of  these  package*  1* 
then  given.  Last,  Section  2  describe*  the  approach  which  was 
taken  in  developing  the  operational  and  functional  descriptions. 

The  descriptions  then  follow,  with  a  separate  section  devoted  to 
each  AERA  package.  Section  3  thus  discusses  AERA  1.01,  Section 
4  describes  AERA  1.02,  and  so  on.  Within  each  section,  the 
relevant  differences  between  that  package  and  the  previous  one 
are  presented,  together  with  a  brief  evaluation  of  the  signifi¬ 
cance  of  the  enhancements .  This  is  followed  by  a  description  of 
the  interfaces  between  AERA  functions  and  with  other  ATC  func¬ 
tions,  as  they  are  affected  by  the  new  and  enhanced  functions. 
The  interaction  with  the  controller,  and  the  effect  of  the  new 
and  enhanced  functions  on  the  controller  In  the  perforaance  of 
his  duties,  are  then  given  in  the  operational  description. 

After  all  six  AERA  packages  are  described,  Section  9  gives  a 
brief  s ueiia ry  and  conclusion  for  the  report. 
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OVERVIEW  OF  ADVANCED  AUTOMATION  EVOLUTION 


This  section  presents  an  overview  of  the  planned  evolution  of 
the  advanced  automation  functions  in  the  air  traffic  control 
system ,  from  the  present  day  NAS  Stage  A  through  full  auto¬ 
mation  in  AERA  3.  These  packages  were  originally  described  in 
"Evolution  of  Advanced  ATC  Automation  Functions"  [3],  and  the 
characteristics  of  the  packages  described  therein  have  not  been 
substantially  altered  in  this  report.  The  principal  character¬ 
istics  of  each  package  are  largely  determined  by  the  overall 
goals  and  guidelines  which  were  assumed  for  the  advanced 
automation;  those  goals  and  guidelines  are  discussed  below. 

2.1  Goals  of  Staged  Evolution 

2.1.1  Benefits  of  an  Evolutionary  Approach 

As  described  in  "The  AERA  Concept"  [4],  the  objective  of  the 
AERA  automation  program  is  to  improve  the  ATC  system  by  applying 
a  high  degree  of  automation  to  routine  ATC  situations.  Ihis 
would  mean  that  the  ATC  computer  would  anticipate  control 
problems,  generate  resolution  actions,  and  Implement  these 
actions  with  only  a  minimum  level  of  involvement  by  the  control¬ 
ler.  The  controller  would  be  expected  to  continue  as  an  active 
participant  in  the  control  process,  but  on  a  higher  level  of 
Involvement:  setting  the  overall  control  strategy  and  dealing 
with  non-routine  situations,  perhaps,  while  overseeing  the 
routine  performance  of  the  automation. 

This  high  level  of  automation  is  a  major  increase  beyond  the 
capabilities  of  the  current  ATC  system.  There  are  basically  two 
alternative  approaches  for  implementing  this  advanced  utomatlon: 
either  all  at  once  or  as  a  series  of  increments. 

Introducing  full  automation  in  a  single  step  would  be  a  signifi¬ 
cant  and  abrupt  change  in  the  process  of  air  traffic  control.  A 
considerable  amount  of  new  training  would  be  required  for  the 
controllers  to  make  use  of  the  new  functions  and  to  adapt  their 
procedures  to  changes  in  the  existing  functions.  The  changes 
would  be  so  extensive  that  the  new  system  could  just  as  easily 
be  completely  independent  of  the  present  system.  This  would 
allow  considerable  freedom  in  designing  the  usage  of  the  new 
system  which  could  result  in  a  better  system  of  automation. 

Any  change  to  the  ATC  system  is  thoroughly  tested  before  being 
implemented  in  the  field.  Even  so,  further  revisions  are 
frequently  required  as  a  result  of  unforeseen  operational 


requirements  or  field  conditions  which  were  not  adequately 

considered*  A  radical  change  to  the  ATC  system,  such  as  a 

switch  from  NAS  Stage  A  to  full  AERA,  would  be  subject  to 

extremely  extensive  testing,  but  even  then  problems  might  arise 
in  the  field,  and  reverting  back  to  the  previous  system  would  be 
very  difficult* 

However,  if  the  new  functions  were  introduced  incrementally, 
each  step  could  be  proven  in  the  field  before  the  next  package 
of  automation  is  introduced.  With  proper  design,  existing 
functions  would  be  little  changed  by  the  introduction  of  the  new 
automation  features,  making  it  easier  to  temporarily  revert  to 
the  previous  system  in  the  event  of  operational  problems  with 
the  new  features* 

Other  possible  advantages  of  the  gradual  transition  to  full 

automation  include  reduced  developmental  risk  and  improved 
controller  confidence.  For  all  these  reasons,  a  strategy  of 
gradual  evolution  was  followed  in  developing  the  following  set 
of  AERA  packages* 

2*1*2  Evolution  Strategy 

Several  guidelines  were  utilized  in  developing  the  specifics  of 
the  following  automation  packages. 

Each  package  is  intended  to  provide  a  tangible  improvement  in 
operational  capability  compared  to  the  previous  one*  This  means 
that  each  step  offers  benefits  to  the  controller  or  the  user,  or 
both,  without  penalizing  or  degrading  the  operation  of  any  of 
the  previously  existing  functions. 

Each  automation  package  consists  of  a  number  of  separate 
functional  enhancements,  designed  to  operate  in  coordination. 
Nevertheless,  there  is  considerable  design  and  operational 
flexibility  inherent  in  each  of  the  following  packages,  allowing 
for  changes  to  the  development  or  implementation  of  the  packages 
if  necessary*  Each  package  represents  a  complete  and  stable 
system  that  could  form  the  basis  for  the  next  incremental 
package,  or  could  if  necessary  support  the  ATC  system  without 
further  enhancements. 

The  evolutionary  stages  of  AERA  can  be  characterized  by  an 
Increasing  level  of  automation.  The  first  two  steps,  comprising 
AERA  1,  provide  problem-detection  and  planning  tools  for  the 
controller’s  use.  The  features  of  AERA  1  will  provide  most  of 
the  benefits  to  the  airspace  users  to  be  derived  from  advanced 
automation.  The  steps  of  AERA  2  introduce  computer-aided 


problem  resolution  as  well,  with  increasingly  specific  resolu¬ 
tions.  Increased  controller  productivity  is  expected  as  a 
result  of  ARRA  2.  Finally,  in  AERA  3,  computer-aided  implemen¬ 
tation  of  selected  resolutions  are  Implemented  In  the  form  of 
automatic  transmission  of  the  resolution  to  the  Involved 
aircraft. 

This  increasing  level  of  automation  la  made  possible  in  part  by 
the  improving  quality  of  data  made  available  to  the  planning 
functions.  This  is  due  partly  to  improvements  in  the  automation 
algorithms  and  partly  to  enhancements  external  to  the  automation 
functions,  such  as  Improved  surveillance  sensors.  However,  the 
main  factor  in  improving  the  data  quality  will  be  improved 
Interactions  between  the  automation  functions.  Improved 
predictions  about  the  future  position  of  the  aircraft  allow  for 
more  accurate  detection  of  control  problems  such  as  conflicts. 
This  in  turn  allows  for  the  earlier  resolution  of  these  problems 
and  encourages  the  controller  to  specify  to  the  system  more  of 
the  control  plan  for  each  aircraft  (i.e.,  the  long  range 
strategy  for  integrating  that  aircraft  into  the  overall  flow  of 
traffic,  including  metering  goals  and  aircraft  priorities). 
With  this  improved  information  come  still  more  accurate 
predictions  of  position,  problems,  and  resolutions.  There  is, 
therefore,  a  cumulative  effect  on  the  accuracy  of  the  AERA 
processes,  as  the  functions  are  implemented. 

2.2  Description  of  the  AERA  Packages 

Figure  2-1  presents  a  simplified  overview  of  the  development  of 
the  AERA  packages.  In  this  diagram,  each  vertical  column 
represents  a  separate  stage  of  automation;  enhancements  to  the 
functional  areas  are  arrayed  horizontally,  from  left  to  right. 

The  initial  package  of  advanced  automation  features,  referred  to 
as  AERA  1.01,  will  be  implemented  as  part  of  the  initial 
Advanced  Automation  System  of  hardware  and  software.  AERA  1.01 
will  Introduce  automated  planning  tools  which  use  the  aircraft 
flight  plan  data,  and  will  consist  of  four  functions: 

•  Trajectory  Estimation  will  calculate  the  flight  path  of 
the  aircraft  in  three  spatial  dimensions  (x,y,z)  and 
time  (t),  based  on  information  from  flight  plans  and 
other  sources. 

s  Flight  Plan  Conflict  Probe  will  compare  aircraft 
trajectories  in  order  to  test  for  conflicts  between 
aircraft,  situations  in  which  separation  minima  are 
predicted  to  be  violated. 
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FIGURE  2-1 

OVERVIEW  OF  THE  AERA  PACKAGES 


•  Airspace  Probe  will  use  the  aircraft  trajectory  to  test 
for  conflicts  with  specific  static  adapted  airspace 
volumes  (special  use  areas  and  terrain). 

•  Sector  Workload  Probe  will  display  various 
workload-related  measures  to  supervisory  personnel  to 
assist  in  determining  sector  manning  levels  and/or 
resectorlzlng  as  necessary  to  balance  workload. 

AERA  1.02  will  add  several  new  functions  and  will  integrate  the 
advanced  planning  functions  more  closely  with  the  existing 
functions.  A  Long  Range  Probe  capability  will  be  added  to  help 
the  controller  evaluate  off-airway  route  requests  which  extend 
beyond  the  prediction  horizon  of  the  Conflict  Probe.  The 
Airspace  Probe  will  be  enhanced  to  consider  conflicts  with 
dynamic  weather  areas  as  well  as  with  static  areas  of  special- 
use  airspace.  Metering  advisories  to  the  controller  will  be 
checked  for  potential  conflicts  before  being  displayed.  The 
controller  will  be  able  to  make  more  of  the  overall  control  plan 
known  to  the  automation  system,  which  in  turn  will  provide 
reminders  of  planned  actions  at  the  appropriate  times. 

In  AERA  2,  these  functions  will  be  enhanced  to  improve 
controller  productivity.  Three  steps  are  planned  for  AERA  2. 
The  first,  AERA  2.01,  will  introduce  a  computer  capability  for 
helping  the  controller  to  resolve  those  problems  detected  by  the 
other  advanced  automation  functions.  Initially,  this  capability 
will  consist  of  general  advisories  presented  to  the  controller, 
with  the  controller  adding  the  necessary  details.  For  example, 
the  resolution  advisory  could  indicate  the  aircraft  involved  in 
a  conflict  and  the  appropriate  resolution  maneuver,  such  as  a 
climb,  but  leave  it  to  the  controller  to  specify  the  final 
altitude  assignment.  As  these  conflict  resolutions  are  made 
known  to  the  system  by  the  controller,  the  system  can  help 
remind  the  controller  to  execute  the  different  steps  of  the 
resolution  at  the  appropriate  time, 

AERA  2.02  will  see  further  enhancements  to  the  resolution 
capability.  The  controller  will  be  presented  with  several 
specific,  complete  resolutions;  if  one  is  selected,  and  the 

aircraft  is  datalink -equipped,  the  resolution  will  be 

automatically  converted  into  a  clearance  to  be  datalinked  to  the 
aircraft  upon  approval.  This  package  will  also  include 
enhancements  to  the  NAS  Conflict  Alert  function,  to  reduce  the 
occurrence  of  false  alarms  by  considering  information  about 
aircraft  intent,  as  appropriate,  as  well  as  radar  track  data. 
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This  enhanced  function  Is  tensed  the  Separation  Assurance 
Monitor* 


The  next  automation  package  sets  the  stage  for  the  fully 
automated  ATC  system  referred  to  as  AERA  3*  In  AERA  2*03,  only 
a  single  resolution  Is  displayed  to  the  controller*  If  the 
resolution  Is  approved.  It  Is  translated  Into  a  clearance  which 
Is  presented  to  the  controller  and  automatically  datallnked  to 
the  equipped  aircraft  unless  specifically  vetoed  by  the  control¬ 
ler.  The  resolutions  and  reminders  are  assigned  priorities  by 
the  system,  based  upon  a  global  planning  perspective* 

Finally,  full  automation  is  applied  to  the  ATC  system  in  AERA  3, 
allowing  routine  planning  and  resolution  actions  to  be  conducted 
without  controller  intervention. 

2*3  Approach 

The  above  survey  of  the  AERA  packages  has  been  provided  In  order 
to  establish  a  sense  of  how  the  ATC  system  Is  seen  to  develop 
over  time  with  the  Introduction  of  the  automated  functions,  and 
how  the  Individual  packages  contribute  to  the  goal  of  full  ATC 
automation.  In  the  following  sections,  the  individual  packages 
will  be  discussed  in  greater  detail.  In  particular,  a  functional 
and  operational  description  of  each  package  will  be  presented* 

The  functional  description  is  the  "behind -the-panel"  view  of  the 
automation*  Some  details  may  be  given  on  the  processing 
techniques  and  algorithms  of  each  function,  but  the  main 
emphasis  will  be  on  the  role  of  each  particular  function  within 
the  overall  ATC  automation  system.  The  flow  of  information  and 
control  between  functions  will  be  discussed  on  a  high  level. 
Details  of  timing,  protocols,  exact  control  sequences,  and  other 
important  items  will  need  to  be  left  unaddressed  until  the 
functions  are  further  developed. 

In  contrast  to  the  functional  description,  the  operational 
description  of  the  AERA  packages  presents  the  functions  as  they 
appear  to  the  controller*  The  operational  description  discusses: 

•  When  and  how  the  AERA  functions  may  be  invoked* 

•  What  information  should  pass  between  the  controller  and 
the  system* 

•  The  effect  of  the  automated  functions  on  the 
controller's  actions* 
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•  How  the  controller  is  to  Integrate  the  new  functions 
into  the  process  of  controlling  air  traffic. 

In  order  to  avoid  unnecessary  duplication,  the  following 
operational  and  functional  descriptions  will  only  discuss  the 
new  features  of  each  package  and  the  associated  changes  to  the 
ATC  system.  Any  aspects  of  the  ATC  automation  which  are  not 
discussed  may  be  assumed  to  have  not  changed  significantly 
compared  to  the  previous  AERA  package.  As  a  result  of  this 
approach  to  the  descriptions,  the  following  sections,  taken 
individually,  are  not  complete  descriptions  of  the  ATC  system  at 
the  time  each  package  is  implemented;  rather,  the  descriptions 
are  cumulative,  building  upon  previous  sections  in  the  same  way 
each  new  package  builds  upon  the  previous  AERA  packages. 

Since  these  systems  have  not  yet  been  Implemented,  the 
functional  and  operational  descriptions  are  only  conceptual. 
However,  they  are  based  upon  a  familiarity  with  the  current  ATC 
system  and  with  the  current  state  of  AERA  development.  The 
resulting  descriptions  are  subject  to  change  as  more  is  learned 
about  the  AERA  functions  and  as  development  proceeds,  but  at  the 
present  time  these  descriptions  should  provide  the  best 
available  Information  on  the  AERA  packages. 

It  is  expected  that  more  complete  descriptions  of  the  individual 
AERA  packages  will  be  produced  as  part  of  the  developmental 
process.  The  first  package,  AERA  1.01,  has  already  been 
described  In  the  MITRE  report  "Operational  and  Functional 
Description  of  AERA  1.01"  [5] • 


3,  AERA  1.01 


The  first  AERA  features  to  be  implemented  are  contained  in  the 
package  referred  to  as  AERA  1.01.  This  package  will  be 
installed  as  part  of  the  initial  Advanced  Automation  System  of 
hardware  and  software. 

3.1  Enhancement  Features 


AERA  1.01  consists  of  four  automation  features: 

•  Trajectory  Estimation 

•  Flight  Plan  Conflict  Probe 

•  Airspace  Probe 

•  Sector  Workload  Probe 

The  following  section  briefly  describes  the  role  of  each  of 
these  functions. 

3.1.1  Trajectory  Estimation 

NAS  Stage  A  includes  a  Route  Conversion  function  which  checks 
the  filed  horizontal  route  of  flight  for  validity,  substitutes 
applicable  preferential  routes,  expands  the  route  to  include 
intermediate  fixes,  and  determines  the  Calculated  Time  of 
Arrival  (CTA)  at  each  fix. 

The  Trajectory  Estimation  (TJE)  function  in  AERA  1.01  augments 
the  Route  Conversion  function  to  provide  more  accurate  four¬ 
dimensional  (4-D)  flight  path  estimates,  called  "trajecto¬ 
ries."  Information  from  the  aircraft's  cleared  flight  plan 
through  the  ACF  airspace  is  supplemented  with  available 
information  about  winds  and  temperatures  aloft  and  other 
Information  from  the  AAS  data  base  to  produce  a  series  of 
points  in  x,  y,  z,  and  t  that  define  the  aircraft's  path.  The 
aircraft's  desired  climb/descent  profile  will  be  used,  as 
known,  to  estimate  its  vertical  trajectory. 

Amendments  to  a  flight  plan  will  trigger  a  reconversion  (if 
needed)  and  reestimation  of  the  balance  of  the  flight's  trajec¬ 
tory.  If  the  difference  between  an  aircraft's  trajectory  and 
its  radar  track  position  exceeds  a  parameter,  as  determined  by 
the  Conformance  Monitoring  function  (which  is  similar  to  the 
Flight  Plan  Association  Checking  task  in  NAS),  an  adjustment  is 
made  to  the  estimate  of  the  aircraft's  speed  (based  on  the 
radar  track  history)  to  account  for  the  error  prior  to  reesti- 
matlng  the  trajectory  from  the  aircraft's  present  position. 
This  is  referred  to  as  "resynchronization." 
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The  Trajectory  Estimation  function  is  critical  to  the  success¬ 
ful  implementation  of  AERA,  since  the  probes  require  more 
accurate  trajectory  information  than  is  available  from  NAS 
Stage  A,  especially  in  the  vertical  dimension. 

The  importance  of  an  accurate  trajectory  to  the  operation  of 
the  AERA  control  functions  requires  that  TJE  be  supplied  with 
the  most  current  data  on  expected  aircraft  performance  as 
identified  by  the  aircraft’s  current  clearances.  The  control¬ 
ler’s  compliance  in  following  what  are  considered  today  to  be 
good  control  practices  (in  terms  of  entering  amendment  messages 
when  new  clearances  are  given  and  maintaining  conformity 
between  the  aircraft  and  its  cleared  route)  is  critical  to  the 
accuracy  of  the  trajectories  and  thereby,  the  accuracy  of  the 
other  planning  and  control  functions. 

3.1.2  Flight  Plan  Conflict  Probe 

The  Flight  Plan  Conflict  Probe  (FPCP)  function  compares  the 
trajectories  of  aircraft  within  the  ACF  Planning  Region  to 
detect  future  situations  in  which  applicable  separation 
criteria  between  aircraft  may  be  violated.  FPCP  automatically 
monitors  all  trajectories  within  the  Planning  Region,  which 
extends  beyond  the  boundaries  of  the  ACF  to  ensure  thorough 
coverage  of  all  flights. 

The  Conflict  Alert  function  plays  a  similar  role  in  NAS  Stage 
A,  but  with  some  Important  differences.  Conflict  Alert  uses 
radar  track  data,  independent  of  the  flight  plan,  to  detect 
possible  violations  of  radar  separation  criteria  within  the 
next  two  minutes.  Flight  Plan  Conflict  Probe,  as  its  name 
implies,  uses  flight  plan  information  to  detect  possible 
separation  violations  as  long  as  twenty  minutes  or  more  in 
advance. 

The  Flight  Plan  Conflict  Probe  function  is  triggered  automat¬ 
ically,  and  may  also  be  invoked  directly  by  the  controller  to 
probe  a  trial  amendment  for  the  aircraft.  This  capability  is 
referred  to  as  the  Trial  Plan  Probe  (TPP).  The  goal  of  Trial 
Plan  Probe  is  to  allow  the  controller  the  flexibility  of  test¬ 
ing  various  changes  to  a  flight  plan  without  changing  the  data 
base  or  committing  the  aircraft  to  unneeded  plan  modifications. 

In  the  later  AERA  packages,  the  performance  of  the  Flight  Plan 
Conflict  Probe  is  expected  to  be  improved  as  a  result  of 
additional  data,  refinements  to  the  algorithms,  and 
enhancements  to  other  functions.  In  addition,  resolutions  to 


the  detected  conflicts  will  be  generated  automatically  in  the 
later  packages. 

3.1.3  Airspace  Probe 


Adapted  within  the  data  base  of  each  en  route  facility^  com¬ 
puter  system  are  airspace  volumes  designated  as  Restricted 
Areas,  Military  Operation  Areas,  Warning  Areas,  etc.  These 
designated  special  use  airspaces  have  an  altitude  floor  and 
ceiling,  specific  geographic  boundaries,  and  times  of 
activation/deactivation  associated  with  them.  Most  aircraft 
are  required  to  avoid  these  areas.  Such  airspace  polygons  can 
also  be  used  to  define  terrain  to  be  avoided. 

The  Airspace  Probe  (AP)  function  is  designed  to  probe  a  flight 
throughout  the  Planning  Region  of  the  ACF  to  detect  violations 
of  the  designated  airspaces.  If  an  airspace  conflict  is 
detected,  a  conflict  message  will  be  generated  and  displayed  to 
the  appropriate  controller. 

The  Airspace  Probe  function  will  be  particularly  useful  in 
processing  requests  for  off-airway  User-Preferred  Routes 
(UPRs),  for  the  early  detection  of  conflicts  with  special  use 
airspace  by  direct  flights  and  other  UPRs.  In  later  AERA 
packages,  this  function  will  be  enhanced  to  allow  detection  of 
conflicts  with  dynamic  airspace  regions,  such  as  severe  weather 
areas.  A  resolution  capability  will  also  be  provided. 

3.1.4  Sector  Workload  Probe 


As  an  aid  to  managing  the  workload  associated  with  the  traffic 
peaks  in  a  center,  a  method  of  predicting  some  workload-related 
measures  at  the  sector  level  has  been  included  in  the  AAS 
Specification  [6].  Sector  Workload  Probe  computes  these  esti¬ 
mated  measures  and  displays  them  to  the  Area  Supervisor  or  Area 
Manager  who  can  use  them  to  help  with  decisions  on  sector 
manning  or  combining /decombining  sectors. 

The  workload  measures  are  calculated  for  successive  time 
intervals  up  to  a  limit  (e.g.,  for  each  fifteen  minutes  over 
the  next  hour).  They  include: 

•  the  aircraft  count  in  the  sector 

•  a  weighted  sum  of  anticipated  ATC  actions  (such  as 
procedural  altitude  changes,  speed  reductions,  and 
handof f s) 
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•  a  count  of  encounters  that  have  been  detected  by  the 
Flight  PLan  Conflict  Probe  and  Airspace  Probe  functions 


*  a  measure  of  traffic  density 
3.1.5  Other  Automation  Enhancements 


In  addition  to  the  AERA  1.01  features,  the  AAS  software  will 
include  several  automation,  functions  which  are  not  available  in 
the  present  NAS  Stage  A.  Some  of  these  functions  are  being 
developed  at  this  time,  and  will  be  installed  in  the  "host’* 
computers;  others  have  been  specified  in  the  AAS  Specification 
[6]  to  be  part  of  the  initial  AAS  software. 

These  functions  will  Include  the  following: 

•  Improvements  to  En  Route  Metering — NAS  Stage  A  includes 
the  first  version  of  En  Route  Metering,  ERM  I,  which 
computes  and  displays  the  delay  to  be  absorbed  by 
specific  flights.  ERM  II,  which  gives  the  controller 
advisories  on  the  most  fuel-efficient  means  to  absorb 
that  delay,  will  be  introduced  with  the  host  computers. 
In  the  AAS,  this  function  will  be  enhanced  to  allow 
metering  of  flights  to  any  fix  or  boundary,  as  well  as 
to  an  airport  metering  fix. 

•  Conflict  Resolution  Advisories — The  CRA  function 
provides  the  controller  with  a  display  of  possible 
alternatives  for  the  resolution  of  conflicts  between 
controlled  aircraft,  as  detected  by  the  Conflict  Alert 
function.  In  the  AAS,  this  function  will  be  enhanced  to 
also  generate  alternative  resolutions  for  conflicts 
detected  with  terrain  and  special  use  airspace. 

•  IFR-VFR  Conflict  Alert — This  function  extends  the 
Conflict  Alert  function  to  all  pairings  of  Mode  C 
equipped  uncontrolled  (VFR)  aircraft  with  controlled 
(IFR)  aircraft  in  en  route  airspace. 

In  addition  to  these  functions,  all  the  automation  functions  of 
NAS  Stage  A  are  assumed  to  be  available  in  the  AAS  as  well, 
although  details  ot  processing  or  presentation  may  differ.  The 
AERA  1.01  functions  are,  for  the  most  part,  additions  to  these 
functions  rather  than  replacements  for  them. 
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3.2  Functional  Description 

In  order  to  describe  the  functions  and  interfaces  for  each  AERA 
package,  the  AERA-related  functions  in  the  AAS  have  been 
organized  into  several  functional  areas.  In  the  following 
sections,  this  organization  will  be  discussed  first,  followed 
by  the  descriptions  of  each  functional  area  in  AERA  1.01. 

3.2.1  Organization  of  the  AERA  Functions 

For  the  purposes  of  this  document,  the  AERA-related  automation 
functions  can  be  categorized  as  either  Planning  Functions  or 
Control  Functions.  The  Planning  Functions  help  to  organize  and 
control  traffic  with  a  time  horizon  of  20  minutes  or  so;  these 
functions  are  therefore  strategic  aids  to  the  sector 
controller.  The  Control  Functions  are  more  concerned  with 
implementing  the  strategic  plan  and  dealing  with  problems  that 
are  more  tactical  in  nature,  with  a  shorter  time  horizon  (e.g., 
five  minutes  or  less). 

The  Planning  Function  category  consists  of  the  following 
functional  areas: 

•  Trajectory  Estimation — constructs  the  four -dimensional 
estimate  of  the  aircraft’s  expected  trajectory. 

•  Problems  Prediction — encompasses  the  Flight  Plan 
Conflict  Probe,  the  Airspace  Probe,  Long-Range  Probe, 
and  Metering  Prediction. 

•  Solutions  Planning — contains  the  automated  planners, 
such  as  Metering  Planning,  Conflict  Resolution  Planning 
and  Deviation  Resolution  Planning  in  later  packages. 
These  planners  control  the  automatic  addition  of  Planned 
Actions  to  an  aircraft’s  trajectory  to  accomplish 
various  planning  objectives. 

The  following  functional  areas  are  considered  under  the  heading 
of  Control  Functions: 

•  Plan  Implementation — contains  the  functions  that  carry 
out  the  intent  of  the  AERA  planning  functions.  Plan 
Implementation  functions  include  Conformance  Monitoring 
and  Tactical  Execution. 

•  Tactical  Problem  Detection — monitors  the  real-time 

situation  in  the  AERA  control  region  to  identify  tactical 


control  problems,  primarily  using  radar  track  data. 
Detected  conflict  situations  are  presented  to  the 
controller  for  evaluation/action.  The  functions  include 
the  Separation  Assurance  Monitor  and  Airspace  Violation 
Detection . 

•  Tactical  Problem  Resolution — determines  corrective 

actions  required  to  resolve  near  term  violations  of 
aircraft  separation  standards  and  airspace  conflicts. 

Each  functional  area  consist  of  one  or  more  specific  func¬ 
tions.  A  consistent  set  of  functional  areas  will  be  used  in 
this  report  to  characterize  the  different  AERA  packages, 
although  the  functions  within  each  area  will  be  enhanced  and 
new  functions  will  be  added  as  AERA  evolves.  These  functional 
areas  will  be  used  to  describe  the  relations  between  the  AERA 
functions  and  between  AERA  and  other  ATC  automation.  As  such, 
they  represent  general  capabilities  of  the  ATC  automation 
rather  than  specific  software  modules. 

Figure  3-1  illustrates  the  internal  components  of  AERA  1.01. 
The  components  on  the  left  side  cf  the  diagram  represent  the 
Planning  Functions,  and  the  components  on  the  right  represent 
the  Control  Functions.  The  elements  within  the  dashed  lines 
are  those  elements  of  1.01  which  are  AERA-rela ted .  The  diagram 
is  intended  to  show  the  relationships  of  the  components  to  each 
other  and  to  other,  external  elements  of  the  ATC  system.  It  is 
not  intended  to  show  sequence  of  processing  actions.  In  the 
discussion  of  each  component,  its  place  In  the  processing 
sequence  will  be  discussed. 

3.2.2  Trajectory  Estimation 

An  algorithmic  specification  for  Trajectory  Estimation  [7]  has 
been  developed.  "Trajectory  Estimation,”  used  as  the  name  of 
the  specification,  logically  groups  three  functions: 
Trajectory  Estimation  and  two  ancillary  functions  that  feed 
Trajectory  Estimation  called  Nominal  Plan  Builder  and 
Resynch roniza  tion . 

In  NAS  Stage  A,  the  Route  Conversion  function  alters  pilot- 
requested  routes  to  conform  to  established  preferential  routes 
in  terminal  areas.  Nominal  Plan  Builder  provides  an  analogous 
service  in  the  vertical  dimension,  Interpreting  stored  data  on 
established  ATC  procedures  in  order  to  predict  the  aircraft's 
vertical  profile. 


Trajectory  Estimation  constructs  a  four-dimensional  (4-D) 
ground  referenced  path,  or  trajectory,  for  each  flight  plan  it 
receives.  These  trajectories  are  based  upon  the  aircraft’s 
cleared  flight  plan  and  a  list  of  "Planned  Actions"  which 
reflect  pilot  intents  implied  by  the  flight  plan,  and 
controller  intents  either  implied  by  routine  ATC  procedures  or 
explicitly  made  known  by  the  controller.  Four  types  of  planned 
actions  are  supported  in  ARRA  1.01: 

•  Altitude  change  (possibly  with  restrictions) 

•  Speed  change 

•  Fully-specified  vectors 

•  Hold  at  a  fix 

The  trajectories  also  include  consideration  of  the  effects  of 
winds  and  temperatures  aloft  and  atmospheric  pressure. 

The  Resynchronization  function  supports  the  re synchronization 
process.  The  internal  estimate  of  the  aircraft's  ground  speed 
is  modified  to  account  for  discrepancies  between  the  aircraft's 
observed  speed  and  its  rlight  plan  speed,  which  may  be  due  to 
errors  in  the  stored  wind  values  used  for  the  calculation. 
Trajectory  Estimation  then  recomputes  the  trajectory. 

The  modeled  trajectory  is  composed  of  an  ordered  list  of  points 
representing  a  4-D  estimate  of  aircraft  position  at  all 
locations  along  the  cleared  route  of  flight  within  the  Planning 
Region.  The  output  of  TJE  (the  completed  aircraft  trajectory) 
is  accessed  by  the  components  requiring  the  trajectory  as  input. 

3. 2. 2.1  Execution  Stimuli 

Trajectory  Estimation  will  be  activated  whenever  a  trajectory 
must  be  created  or  revised,  including  automatic  updates. 

A  request  to  remodel  an  amended  or  revised  flight  plan  may  be 
generated  as  a  result  of  a  controller  input  or  automatically  by 
the  Conformance  Monitoring  function,  when  a  longitudinal  error 
of  sufficient  magnitude  is  detected  between  the  tracked 
position  of  the  aircraft  and  its  trajectory.  A  lateral  or 
vertical  deviation  will  be  detected  by  the  automation  and 
indicated  to  the  controller,  as  in  NAS  Stage  A,  but  it  will  be 
the  controller's  responsibility  to  restore  conformance  with  the 
trajectory. 
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3. 2. 2*2  External  Interfaces 


Trajectory  Estimation  receives  information  on  flight  plans, 
aircraft  performance  characteristics,  and  meteorological 
conditions  from  other  automation  functions  and  system  data 
bases . 

Information  on  new  flights  or  current  flights  with  route  amend¬ 
ments  is  received  from  the  AAS  Route  Conversion  function  in  the 
form  of  processed  flight  plans.  The  converted  plau  is  a 
horizontal  route  plan  which  consists  of  the  pilot's  original 
filed  plan,  modified  to  accommodate  established  procedures  such 
as  preferential  routes  (PDARs,  PARs ,  etc.)  or  Severe  Weather 
Avoidance  Plans,  and  then  translated  into  a  sequence  of  (x,y) 
points . 

Aircraft  performance  data  is  used  by  TJE  to  create  a  trajectory 
based  on  the  expected  performance  of  a  particular  aircraft  or 
class  of  aircraft.  In  AERA  1.01,  the  performance  data  may 
consist  of  general  characteristics  per  aircraft  type  (e.g., 
climb  and  descent  gradients,  minimum  and  maximum  speeds,  etc.) 
obtained  from  manufacturer's  specifications  and  airlines' 
operational  procedures.  Data  on  individual  aircraft  will  also 
be  maintained,  as  available.  TJE  will  use  the  best  available 
data  in  calculating  trajectories. 

The  Trajectory  Estimation  process  also  makes  use  of  weather 
information  when  constructing  trajectories.  This  information 
(winds  and  temperatures  aloft)  is  obtained  from  the  Central 
Weather  Processor  (CWP),  which  has  consolidated  information 
from  the  National  Weather  Service  (NWS),  pilot  reports,  and 
other  sources.  In  later  stages  of  AERA,  the  Trajectory 
Estimation  process  may  provide  feedback  on  wind  information. 
Wind  error  accumulation  information,  deduced  from  aircraft 
deviation  data,  would  be  supplied  to  the  Center  Weather  Service 
Unit  (CWSU)  for  evaluation  and  possible  use. 

Input  to  Trajectory  Estimation  i3  also  obtained  from  the 
controller.  The  controller  is  responsible  for  updating  the 
trajectory  data  to  reflect  all  clearances  given  to,  and 
acknowledged  by,  aircraft  under  his  control.  This  is  done  by 
entering  flight  plan  amendment  messages  whenever  a  change  is 
made  to  the  aircraft's  currently  cleared  flight  plan.  Input  of 
these  messages  is  an  extremely  Important  interface  because  It 
keeps  the  projected  trajectories  in  close  correspondence  with 
the  ATC  clearances  as  known  by  the  pilot,  which  is  necessary 
for  the  probe  functions  to  detect  conflicts. 


If  the  trajectory  Is  not  kept  up  to  date,  the  aircraft’s 
expected  position  may  not  be  accurate  and  the  probes  may  be 

compromised  since  they  will  not  have  access  to  valid 
trajectories.  Whether  or  not  the  probes  should  operate  on 

invalid  trajectories,  such  as  out-of-conformance  aircraft  or 
aircraft  on  vectors  which  have  not  been  incorporated  into  the 
trajectory,  will  need  to  be  resolved.  On  the  one  hand,  the 

trajectory  is  known  to  be  invalid,  but  on  the  other  hand,  it 

represents  the  best  information  known  to  the  system. 

Operations  involving  invalid  trajectories  would  need  to  be 

specially  flagged  to  alert  the  controller. 

The  controller  does  not  normally  receive  output  directly  from 
the  Trajectory  Estimation  function,  except  when  display  of  an 
aircraft’s  trajectory  is  specifically  requested.  Trajectory 
information  might  aLso  be  displayed  in  connection  with  a 

detected  conflict,  or  other  output  of  another  automation 

function . 

3. 2. 2. 3  Internal  Interfaces 


Trajectory  Estimation  and  its  ancillary  functions  do  not 
receive  input  data  from  anv  of  the  other  AERA  1.01  functions; 
all  of  the  Input  comes  from  external  sources ,  as  described 
above.  The  other  three  AERA  1.01  functions  receive  the 
trajectories  from  TJE  as  part  of  their  input.  Flight  Plan 
Conflict  Probe  and  Airspace  Probe  use  the  trajectories  to 
detect  future  violations  of  separation  standards;  Sector 
Workload  Probe  uses  the  trajectories  to  derive  expected  traffic 
levels  and  characteristics. 

3.2.3  Problems  Prediction 


The  functional  area  of  "Problems  Prediction"  includes  functions 
whose  purpose  is  to  detect  situations  which  must  be  brought  to 
the  attention  of  a  controller  or  supervisor  or  presented  to  the 
automated  system  for  resolution.  In  AERA  1.01,  these  functions 
include  Flight  Plan  Conflict  Probe,  Airspace  Probe,  and  Sector 
Workload  Probe.  More  Information  Is  available  In  the  algo¬ 
rithmic  specifications  for  these  functions  [8,9,10]. 

Flight  Plan  Conflict  Probe  uses  a  coarse  filtering  process  to 
eliminate  those  trajectories  that  are  too  far  removed  from  that 
of  the  subject  aircraft  to  be  considered  in  further  prediction 
processing.  A  fine  filter  is  then  employed  to  determine  if  the 
applicable  separation  criteria  will  be  violated.  If  so,  the 
predicted  violation  is  classified  as  an  "encounter,"  and  a 
description  of  the  violation  Is  stored.  Not  all  encounters 
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immediately  meet  the  criteria  for  display  to  a  controller  (the 
predicted  violation  may  be  too  far  off  in  the  future,  for 
example).  At  the  proper  time,  information  concerning  the 
encounter  will  be  displayed  to  the  appropriate  controller(s) 
for  attention. 

Airspace  Probe  compares  the  trajectory  of  the  subject  aircraft 
against  all  airspace  and  terrain  polygons.  As  in  FPCP,  a 
coarse  filtering  process  is  implemented  to  quickly  eliminate 
those  polygons  which  are  not  in  close  proximity  to  the 
aircraft's  flight  path.  A  fine  filter  then  tests  for  actual 
intersection  of  the  polygons  by  the  flight  path,  taking  into 
account  applicable  altitude  bounds  and  activation  times  of  each 
polygon.  Any  violation  thus  detected  is  displayed  to  the 
controller  at  the  appropriate  time. 

3. 2. 3.1  Execution  Stimuli 

Flight  Plan  Conflict  Probe  and  Airspace  Probe  are  activated  to 
probe  for  conflicts  for  an  aircraft  when  the  trajectory  for 
that  aircraft  is  first  created  and  whenever  the  trajectory  is 
modified,  including  resynchronization  updates. 

Sector  Workload  Probe  will  execute  upon  receipt  of  an  immediate 
supervisor  request  for  data,  or  at  regular  intervals.  It  will 
update  its  information  upon  a  resectorization,  when  a  new 
flight  plan  is  added  to  the  system,  or  when  an  existing  plan  is 
modified . 

3.2.3. 2  External  Interfaces 

The  principal  external  interface  for  these  three  functions  is 
with  the  human  element  of  the  ATC  system,  the  controller  and 
the  supervisor. 

The  controller  will  receive  the  conflict  information  processed 
by  the  conflict  probes  (Airspace  Probe  and  Flight  Plan  Conflict 
Probe).  Identification  of  detected  conflicts  is  to  be  pre¬ 
sented  on  the  controller's  displays.  Additional  information 
regarding  a  particular  conflict  situation  may  be  available  to 
the  controller  upon  request,  and  may  include  a  graphic  display 
of  the  conflict  situation. 

The  controller  will  be  able  to  initiate  a  probe  for  a  specific 
aircraft  either  by  entering  a  flight  plan  amendment  or  a  trial 
amendment.  These  inputs  are  processed  by  Trajectory  Estimation 
and  therefore  are  not  direct  interfaces  with  the  Problems 
Prediction  functions. 


The  supervisor  will  interface  with  the  Sector  Workload  Probe  to 
obtain  workload  information  for  a  particular  sector  or  sec¬ 
tors.  This  information  is  displayed  as  a  result  of  either  an 
immediate  request  from  the  supervisor  or  a  supervisor-programmed 
request.  Output  to  the  supervisor  consists  of  the  presentation 
of  the  information  from  the  Sector  Workload  Probe  in  the  form 
of  sector^specif ic  reports,  covering  specified  time  intervals. 
Sector  Workload  Probe  also  makes  use  of  data  from  an  external 
source  regarding  sector  characteris tics . 

Similarly,  in  order  to  detect  violations  of  special  use 
airspace  or  conflicts  with  terrain,  the  Airspace  Probe  requires 
definition  of  the  special  use  areas  by  an  external  source. 
This  data  consists  of  such  characteristics  as  identification  of 
the  areas  (e.g.,  by  name  or  number),  a  geographic  description 
of  the  polygons  representing  the  areas,  activation  times,  and 
applicable  altitudes.  The  designated  airspaces  (Restricted 
Areas,  Military  Operation  Areas,  Warning  Areas,  MSAW  polygons, 
etc.)  are  adapted  with  an  altitude  floor  and  celling,  specific 
geographic  boundaries,  the  times  of  activation/deactivation  and 
other  Identifying  information. 

3. 2. 3. 3  Internal  Interfaces 

All  three  of  the  problem  prediction  functions  receive  aircraft 
trajectories  from  TJE  as  part  of  their  inputs.  These  trajecto¬ 
ries  are  accessed  as  required  by  the  individual  functions. 

Additionally,  Sector  Workload  Probe  uses  the  conflict  informa¬ 
tion  from  Airspace  Probe  and  from  Flight  Plan  Conflict  Probe. 
It  has  no  internal  AERA  interface  for  its  output,  but  other 
users  such  as  display  processors  may  access  the  data. 

3.2,4  Solutions  Planning 

The  components  of  AERA  1.01  do  not  include  any  functions  which 
perform  resolution  planning  themselves,  although  they  do 
provide  the  controller  with  planning  tools  (such  as  the  Trial 
Plan  Probe).  A  metering  capability  does  exist  within  the  Air 
Traffic  Control  system  at  the  time  of  AERA  1.01,  but  it  is  not 
an  AERA  function.  According  to  the  AAS  Specification  [6],  the 
AAS  will  allow  metering  to  any  fix  or  boundary,  according  to  a 
rate,  separation,  or  schedule. 

The  metering  capability  will  be  Integrated  with  the  other 
automation  functions  in  later  AERA  packages. 


3.2.5  Plan  Implementation 


1 


The  Plan  Implementation  area  is  composed  of  two  main  functions: 
Conformance  Monitoring  and  Tactical  Execution. 

The  Conformance  Monitoring  function  in  AERA  1.01  is  not  func¬ 
tionally  different  from  Flight  Plan  Association  Checking  in 
today* s  NAS  Stage  A.  The  track  position  of  the  controlled 
aircraft  is  periodically  compared  with  its  expected  position 
according  to  its  cleared  flight  plan.  If  the  longitudinal 
deviation  along  the  route  exceeds  a  (system  parameter)  value, 
arrival  times  along  the  route  are  recalculated  (through  the 
resynchronization  process,  in  AERA).  If  the  lateral  deviation 
exceeds  a  parameter,  or  if  the  aircraft  deviates  from  its 
assigned  altitude,  this  is  indicated  on  the  controller’s 
Situation  Display,  as  in  NAS  today. 

The  Tactical  Execution  functional  component  includes  notifica¬ 
tion  to  the  controller  that  a  previously-planned  action  should 
begin,  and  monitoring  during  the  maneuver  for  conformance.  In 
the  AERA  1.01  time  frame,  only  the  Metering  function  provides 
advisories  to  the  controller  concerning  the  start  of  a 
maneuver,  and  Metering  is  not  an  AERA  1.01  function.  The  other 
duties  of  Tactical  Execution  are  performed  by  the  controller 
without  automation  assistance. 

3.2.6  Tactical  Problem  Detection 


In  AERA  1.01,  this  functional  area  consists  of  the  Conflict 
Alert  and  Minimum  Safe  Altitude  Warning  (MSAW)  functions  of  NAS 
Stage  A,  which  use  radar  track  data  to  detect  imminent  viola¬ 
tions  of  separation  criteria  between  aircraft,  and  between 
aircraft  and  airspace  respectively.  These  functions  will  be 
enhanced  in  the  AAS,  but  are  not  properly  considered  AERA 
functions . 

These  functions  are  activated  by  the  receipt  (from  the  Radar 
Data  Processing  function)  of  new  track  data,  on  each  tracking 
cycle,  for  each  of  the  aircraft  in  the  Planning  Region.  Any 
conflicts  detected  are  reported  to  the  controller,  along  with 
the  associated  Conflict  Resolution  Advisories  (from  the  pre-AAS 
CRA  function).  Conflict  Alert  and  MSAW  results  are  not  used  by 
any  of  the  other  major  AERA-related  components,  and  these 
functions  do  not  use  any  information  from  those  components. 


3,2.7  Tactical  Problem  Resolution 


Once  again,  in  AERA  1.01  there  are  no  AERA-related  functions 
within  this  functional  area.  The  Conflict  Resolution  Advisory 
(CRA)  function  will  have  been  implemented  in  the  pre-AAS  host 
computers  to  generate  and  display  alternative  resolutions  for 
the  conflicts  detected  by  the  Conflict  Alert  and  MSAW  function. 

3.3  Operational  Description 

One  of  the  most  important  interfaces  of  the  AERA  1.01  functions 
is  with  the  human  element  of  the  ATC  system,  the  controllers 
and  supervisors.  Some  of  the  data  flows  from  the  functions  to 
the  human  element  have  already  been  mentioned.  The  following 
paragraphs  will  discuss  how  that  data  may  be  used  by  control¬ 
lers  and  supervisors  in  performing  their  tasks,  how  the  new 
functions  provide  new  control  tools,  and  the  possible  impact  of 
those  tools  on  the  controller’s  and  supervisor’s  responsibil¬ 
ities  , 

For  this  discussion,  an  air  traffic  control  tool  will  be 
defined  as  an  automated  aid  which  is  visible  to  the  controller 
and  which  assists  in  performing  control  tasks.  Four  new  tools 
will  be  introduced  by  AERA  1.01: 

•  Flight  Plan  Conflict  Probe 

•  Airspace  Probe 

•  Sector  Workload  Probe  (for  supervisors) 

•  Trial  Plan  Probe 

Three  of  these  tools  are  directly  linked  by  name  to  three  of 
the  new  functions  of  the  AAS.  The  fourth  tool,  Trial  Plan 
Probe  (TPP),  allows  the  controller  to  submit  a  proposed  flight 
plan  amendment  for  testing  by  the  Flight  Plan  Conflict  Probe 
and  Airspace  Probe  function. 

Since  Trajectory  Estimation  is  not  directly  visible  to  the 
controller,  it  will  not  be  discussed  in  this  operational 
description.  The  controller  does  interact  with  this  function, 
but  only  in  the  context  of  other  activities,  e.g.,  through 
flight  plan  amendment  messages,  as  in  NAS,  or  the  output  of  the 
conflict  probe  functions. 
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3.3.1  Flight  Plan  Conflict  Probe 

3 . 3. 1 . 1  Stimulus 

The  Flight  Plan  Conflict  Probe  operates  whenever  an  aircraft 
trajectory  is  changed,  as  explained  in  Section  3.2.2.  FPCP 
creates  a  list  of  aircraft  "encounters,"  in  which  two 
trajectories  have  been  determined  to  violate  separation 
criteria  at  some  time  in  the  future. 

Once  an  encounter  is  displayed  to  the  controller,  it  may  be 
considered  to  be  a  conflict.  In  today’s  ATC  system,  a 
"conflict"  is  any  situation  in  which  applicable  separation 
criteria  may  or  will  be  violated.  With  today’s  non-automated 
methods  of  conflict  prediction,  conflicts  are  detected,  for  the 
most  part,  when  the  predicted  point  of  violation  occurs  within 
the  sector  in  which  the  involved  aircraft  are  flying  or  within 
the  adjacent  sector.  The  controller  is  directed  to  resolve 
conflicts  promptly. 

The  automated  probes  add  a  new  dimension  to  the  definition  of 
"conflicts"  by  detecting  situations  in  which  separation  minima 
may  be  violated  much  further  in  the  future.  Though  these 
situations  fit  the  current  definition  of  "conflict,"  they  are 
different  from  "conflicts"  detected  in  NAS  Stage  A  in  two 
important  ways.  First,  because  of  the  longer  lookahead  times, 
the  estimates  of  future  aircraft  position  are  more  subject  to 
variations  in  winds  and  aircraft  performance,  and  thus  there 
may  be  less  certainty  that  a  separation  violation  will  occur  if 
no  control  action  is  taken.  Second,  the  long  lead  time  may 
reduce  the  need  for  prompt  resolution.  Requiring  the  control¬ 
ler  to  resolve  such  situations  promptly  may  therefore  increase 
workload  without  significantly  increasing  system  safety.  It  is 
therefore  useful  to  create  a  new  category  of  "possible  problem 
areas"  to  include  these  situations  which  do  not  require  prompt 
resolution. 

Consequently,  AERA  will  consider  two  different  classes  of 
conflicts.  "Priority  Conflicts"  would  be  detected  as  conflicts 
by  the  controller  today,  and  require  prompt  resolution  by  the 
controller.  An  "Advisory  Conflict,"  on  the  other  hand,  is  less 
immediate  and  is  presented  to  the  controller  for  Information 
only.  The  controller  may  choose  to  act  to  resolve  an  Advisory 
Conflict,  or  may  elect  to  defer  action,  allowing  for  the 
possibility  that  the  perceived  conflict  may  "resolve  itself"  as 
the  trajectories  are  updated.  The  Advisory  Conflict  will  be 
automatically  upgraded  to  priority  status  at  the  appropriate 


time,  or  if  trajectories  are  updated  and  the  situation  then 
fits  the  parameters  of  a  "Priority  Conflict." 

3. 3. 1.2  Information  Displayed 

The  two  types  of  conflicts,  Advisory  and  Priority,  are  identi¬ 
fied  to  the  controller  through  advisory  and  priority  messages, 
respectively.  These  messages  may  be  sent  to  the  "involved" 
controllers,  where  an  "involved"  controller  is  one  who  meets 
one  or  more  of  the  following  criteria: 

•  The  controller  has  computer  control  of  one  or  both  of 
the  aircraft  involved. 

•  The  controller  is  in  radio  contact  with  one  or  both  of 
the  aircraft  involved,  if  this  is  known  to  the  AAS. 

•  One  or  both  of  the  aircraft  is  in  the  controller’s 
airspace. 

•  The  predicted  point  of  violation  is  in  the  controller’s 
airspace . 

Particularly  in  complex  situations  such  as  ones  in  which  the 
aircraft  involved  are  currently  in  different  sectors  and  the 
predicted  point  of  violation  is  in  a  third  sector,  the  issue  of 
who  gets  the  advisory  or  priority  message  is  non-trivial  and  a 
subject  for  study. 

Both  the  advisory  and  priority  messages  contain  information 
necessary  for  the  controller  to  identify  the  Advisory  Conflict, 
such  as  identification  of  aircraft  involved,  location  of 
predicted  violation,  time  of  violation,  and  IDs  of  sectors  with 
current  control  of  the  aircraft  involved.  Additional  informa¬ 
tion  may  be  available  to  the  controller  via  an  alternate 
display,  e.g.,  a  graphical  representation  of  the  situation. 

A  control  directive  will  be  required  to  assign  responsibility 
for  initiating  required  coordination  and  for  resolving  the 
Priority  Conflict.  In  most  cases  it  is  expected  that  the 
priority  message  will  be  sent  to  the  controller  in  whose  sector 
the  violation  is  predicted  to  occur,  and  possibly  to  other 
involved  controllers.  The  assignment  of  responsibility  is 
subject  to  modification  and  elaboration  as  a  result  of  further 
study. 
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3. 3. 1.3  Controller's  Response 


The  controller’s  responsibilities  in  AERA  1.01  will  be  defined 
by  control  directives  to  be  developed.  It  is  expected,  however, 
that  the  controller’s  responsibility  with  respect  to  any  Prior¬ 
ity  Conflict,  whether  it  is  detected  by  an  automated  probe  or 
by  mental  monitoring  activities  of  the  controller,  will  be  to 
resolve  it  promptly.  The  Flight  Plan  Conflict  Probe  will 
provide  information  on  the  conflicts  detected  that  will  assist 
the  controller  in  forming  resolutions.  The  responsibility  for 
resolution  will  remain  with  the  controller. 

With  regard  to  Advisory  Conflicts,  it  is  expected  that  the 
controller  will  be  required  by  directives  to  verify  and 
evaluate  the  detected  situation.  The  advisory  message  is 

primarily  a  notice  to  the  controller  to  be  aware  of  and  monitor- 
the  situation  closely  because  it  may  develop  Into  a  Priority 
Conflict.  The  controller  may  optionally  take  measures  to 
resolve  the  situation,  but  such  measures  would  probably  be 
considered  only  as  an  additional  service. 

The  advantages  of  displaying  Advisory  Conflicts  are  related  to 
the  additional  time  provided  to  the  controller  by  the  early 
detection  of  possible  problems.  Early  detection  gives  the 
controller  more  time  to  develop  alternative  resolutions  and 
allows  certain  resolutions  (such  as  speed  adjustments)  which 
require  a  longer  time  to  produce  the  desired  result. 

3.3.2  Airspace  Probe 


3. 3. 2.1  Stimulus 


The  Airspace  Probe  is  invoked  whenever  an  aircraft  trajectory 
is  changed,  as  is  FPCP.  The  new  aircraft  trajectory  is  checked 
for  violations  of  any  static  airspace  regions  which  may  define 
special  use  airspace,  such  as  Restricted  Areas  or  Prohibited 
Areas,  or  which  define  minimum  altitudes  for  flight  above 
terrain.  Airspace  Probe  may  also  be  invoked  if  an  airspace 
region  is  activated  by  a  supervisory  action,  i.e.,  if  a  region 
which  was  previously  available  to  flights  becomes  unavailable. 
In  this  case,  many  trajectories  would  be  processed  sequentially 
by  the  Airspace  Probe. 

The  controller  will  not  necessarily  be  aware  of  the  reason  why 
Airspace  Probe  was  invoked. 
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When  Airspace  Probe  detects  a  violation  of  a  protected  airspace 
region,  the  characteristics  of  the  violation  are  noted  and 
presented  to  the  controller  at  the  appropriate  time*  As  with 
aircraft  conflicts,  there  are  two  types  of  airspace  conflicts, 
advisory  and  priority,  depending  on  factors  such  as  time  until 
violation.  An  Advisory  Airspace  Conflict  will  result  in  an 
advisory  message  to  the  controller;  a  Priority  Airspace  Con¬ 
flict  will  produce  a  priority  message.  In  both  the  advisory 
and  priority  messages,  the  controller  is  presented  with 
information  which  helps  to  identify  the  conflict  and  formulate 
a  resolution,  such  as  aircraft  ID  and  identification  of  the 
violated  airspace.  Additional  information  regarding  the 
conflict  may  be  available  to  the  controller  upon  request, 
including  possible  graphic  display  of  the  conflict  situation. 

3. 3*2.3  Controller  Response 

The  controller’s  responsibility  in  the  AAS  with  respect  to 
special  use  airspace  is  unchanged.  The  controller  must  clear 
nonparticipating  aircraft  via  routing  which  will  provide 
approved  separation  from  the  special  use  airspace,  unless 
clearance  of  nonparticipating  aircraft  in  or  through  the  area 
is  provided  for  in  a  Memorandum  or  Letter  of  Agreement.  It  is 
the  pilot* 8  responsibility  to  be  aware  of  areas  of  special  use 
airspace  and,  unless  permission  to  enter  an  area  has  been 
granted  by  the  using  agency  of  the  area,  to  structure  his 
flight  plan  such  that  these  areas  are  avoided. 

Since  the  Airspace  Probe  examines  the  entire  path  of  an 
aircraft  through  the  Planning  Region,  situations  in  which 
separation  minima  may  be  violated  may  be  detected  considerably 
in  advance  of  the  predicted  violation  (similar  to  Advisory 
Conflicts).  This  advance  notice  of  possible  airspace  conflicts 
has  two  implications: 

•  Very  early  coordination  with  the  pilot  may  be  effected, 
to  allow  the  pilot  to  resolve  the  problem  (since  he  has 
primary  responsibility  for  avoiding  reserved  airspace). 

•  Resolution  of  the  problem  may  be  deferred  (because  of 
controller  workload)  until  the  aircraft  is  within  prox¬ 
imity  of  the  sector  in  which  the  airspace  conflict 
occurs . 


If  an  airspace  conflict  is  detected  more  than  a  stated  (system 
parameter)  number  of  minutes  before  the  predicted  violation,  an 


Airspace  Violation  advisory  message  is  sent  to  the  controller 
then  in  control  of  the  aircraft  (or  about  to  be  in  control  if 
the  aircraft  has  not  yet  entered  the  center).  The  controller's 
responsibility  with  respect  to  an  Airspace  Violation  advisory 
message  will  probably  be  to  treat  the  pilot  notification  as  an 
additional  service.  If  time  and  workload  conditions  permit, 
the  controller  will  do  one  of  the  following: 

•  advise  the  pilot  of  the  problem. 

•  approve/disapprove  pilot-suggested  plan  amendment  (if 
the  pilot  offers  an  amendment). 

•  if  assistance  is  requested  by  the  pilot,  suggest  a  plan 
amendment  which  resolves  the  problem. 

The  controller  will  need  to  indicate  to  the  system  that  the 
pilot  was  notified.  This  tells  the  system  that  no  more 
messages  need  be  given  to  subsequent  controllers  until  a 
priority  message  is  required  (unless  the  predicted  violation 
has  been  resolved).  If,  on  the  other  hand,  the  controller 
receiving  the  message  Is  unable  to  respond  to  it  and  the 
aircraft  is  handed  off  to  the  next  sector,  the  controller  for 
that  sector  will  also  receive  an  Airspace  Violation  advisory 
message.  This  will  continue  until  either  a  controller 
acknowledges  the  message  or  until  the  conflict  is  close  enough 
in  time  that  an  Airspace  Violation  priority  message  is  sent. 

The  purpose  of  the  Airspace  Violation  priority  message  is  to 
inform  the  controller  that  an  aircraft  which  Is  currently  under 
his  control  has  a  conflict  with  an  area  of  special-use  airspace 
or  with  terrain.  The  message  is  sent  to  the  Involved  control- 
ler(s),  even  if  the  previous  advisory  messages  had  been 
acknowledged  and  turned  off  by  the  controller.  The  responsi¬ 
bility  of  the  controller  is  to  determine  if  the  aircraft  should 
be  permitted  to  enter  the  specified  airspace,  and  if  permission 
is  not  to  be  given,  to  provide  the  pilot  with  routing  around 
the  airspace. 

3.3.3  Trial  Plan  Probe 


3. 3. 3.1  Stimulus 


The  Trial  Plan  Probe  is  activated  by  the  controller  to  perform 
a  Flight  Plan  Conflict  Probe  and  an  Airspace  Probe  on  a 
proposed  trial  flight  plan  amendment.  Although  the  Trial  Plan 
Probe  i3,  in  a  sense,  composed  of  these  other  two  functions,  it 
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is  considered  to  be  a  separate  controller  tool  because  it  is 
invoked  differently  and  produces  different  output  from  the 
other  two  functions,  and  serves  a  different  purpose. 

Flight  Plan  Conflict  Probe  and  Airspace  Probe  are  monitoring 
functions,  operating  in  the  background  to  detect  problems 
automatically.  The  controller  only  knows  they  are  working  when 
they  present  advisory  or  priority  messages  on  his  display. 
Trial  Plan  Probe,  on  the  other  hand,  is  directly  usable  by  the 
controller.  TPP  is  a  planning  tool,  not  a  monitor,  which 
assists  the  controller  in  determining  whether  a  trial  plan 
would  resolve  any  previously-identified  conflicts  and/or  create 
new  conflicts.  An  example  of  a  typical  situation  for  use  of 
the  Trial  Plan  Probe  would  be  in  responding  to  a  pilot  request 
for  an  off-airway  segment. 

3.3.3 .2  Information  Displayed 


The  Trial  Plan  Probe  identifies  "potential  conflicts,"  i.e., 
conflicts  involving  the  trial  plan  of  the  subject  aircraft  with 
the  current  trajectories  of  other  aircraft  or  with  special  use 
airspace. 

Trial  plans  will  most  likely  be  input  into  the  computer  in  the 
same  manner  that  all  other  flight  plan  amendments  will  be  input 
by  the  controller,  such  as  through  the  interactive  display  that 
is  one  of  the  components  of  the  Sector  Suite.  When  the 
controller  has  finished  amending  the  plan  and  has  verified  that 
it  is  eutered  into  the  computer  as  intended,  the  probe  will  run 
automatically  without  further  controller  intervention.  The 
results  of  the  probe  are  presented  only  to  the  controller  who 
initiated  it. 

If  a  potential  conflict  is  detected  by  the  probe,  the  control¬ 
ler  will  be  presented  with  a  message  which  contains  information 
necessary  to  identify  the  potential  conflict.  This  information 
is  the  same  as  that  presented  to  the  controller  when  a  real 
conflict  is  detected  by  the  automated  probes,  but  should  clear¬ 
ly  identify  the  conflict  as  being  related  to  a  trial  plan.  If 
the  Trial  Plan  Probe  detects  no  potential  conflicts,  the 
controller  will  be  explicitly  so  informed. 

3. 3.3.3  Controller  Response 

The  controller  uses  the  results  of  the  probe  and  knowledge  of 
the  current  situation  to  decide  whether  or  not  to  implement  the 
trial  plan.  If  the  controller  decides  to  implement  the  trial 
plan,  the  controller  will  transmit  an  appropriate  clearance  to 


3-20 


the  pilot  and  receive  an  acknowledgment.  The  controller  will 
then  indicate  to  the  computer  that  the  trial  plan  is  to  be 
accepted  as  the  current  plan.  If  it  is  determined  that  the 
trial  plan  is  unacceptable,  the  controller  could  reject  it  and 
repeat  the  evaluation  process  with  an  alternative  plan. 

3.3.4  Sector  Workload  Probe 


3. 3. 4.1  Stimulus 


The  Sector  Workload  Probe  (SWP)  Is  intended  to  aid  supervisory 
personnel  such  as  Area  Supervisors  and  Area  Managers  in  planning 
and  conducting  positional  manning  and  combining/decombining 
sectors.  The  supervisor  can  specify  the  conditions  under  which 
SWP  will  be  invoked  to  present  new  or  updated  values  of  the 
workload-related  parameters.  SWP  may  be  invoked  on  immediate 
request  of  the  supervisor,  at  regular  intervals  (e.g.,  every 
five  minutes),  or  when  specified  workload  measures  pass 
threshold  values  set  by  the  supervisor. 

3.3.4. 2  Information  Displayed 

The  probe  information  displayed  to  the  supervisor  shows  the 
current  and  estimated  future  values  of  certain  workload-related 
measures  for  each  sector.  The  information  for  each  sector  may 
include  data  for  various  time  periods  in  the  future  up  to  the 
limit  of  the  probe  function. 

The  following  data  for  each  sector  will  be  provided  by  SWP: 

•  the  current  and  anticipated  number  of  aircraft 

•  the  current  and  anticipated  number  of  conflicts 

•  some  "weighted"  sum  of  anticipated  planned  actions 
related  to  the  number  of  clearance  changes  to  be  issued 

•  the  current  and  anticipated  density  of  the  traffic  flow 

•  the  current  and  anticipated  aggregate  value  of  the 
workload  measures 

The  supervisor  will  be  able  to  specify  the  format  and  content 
of  the  Information  to  be  displayed.  The  time  periods  and  the 
particular  sectors  for  which  the  information  applies  will  also 
be  selectable  by  the  supervisor. 
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It  will  be  the  responsibility  of  the  supervisor  or  manager  to 
interpret  the  significance  of  the  different  categories  of 
information  and  determine  the  manner  in  which  to  use  the 
information.  By  comparing  the  expected  sector  workload  with 
the  current  sector  workload,  the  supervisor  can  determine 
whether  or  not  sectors  need  to  be  combined  or  decombined,  or 
whether  sector  manning  changes  are  needed.  Such  decisions  will 
be  based  upon  experience  and  according  to  ATC  rules  and 
directives. 


AERA  1.02 


AERA  1.02  Is  the  second  of  the  transition  steps,  and  as  part  of 
the  package  known  as  AERA  1,  its  enhancements  focus  mainly  on 
problem-detection  and  planning  tools.  AERA  1.02  adds  several 
new  functions  and  integrates  the  advanced  functions  mo- s 
closely  with  the  other  automation  functions.  The  following 
specific  enhancements  are  discussed  below: 

•  Long  Range  Probe 

•  Dynamic  Airspace  Probe 

•  Conflict-Free  Metering 

•  Controller  Reminders 

Several  other  enhancements  are  also  discussed. 

4 . 1  Enhancement  Fea  tu  re  s 


4.1.1  Long  Range  Probe 

The  Long  Range  Probe  is  a  new  automated  tool  available  in  AERA 
1.02  that  assists  the  sector  controller  in  evaluating  requests 
for  off-airway  User-Preferred  Routes  (UPRs)  by  detecting 

problems  beyond  the  range  of  FPCP. 

Current  difficulties  in  approving  UPRs  include  the  controller’s 
lack  of  knowledge  about  the  traffic  flows  and  densities  beyond 
the  sector  boundaries,  and  about  the  ATC  preferred  route 
structure  that  may  be  unnecessarily  applied  to  the  UPR.  The 
Long  Range  Probe  is  intended  to  provide  the  controller  with 
information  about  areas  of  high  traffic  density  which  might 
affect  the  UPR,  as  well  as  to  facilitate  the  efficient 

application  of  ATC-preferred  routes.  The  process  for 

accomplishing  this  may  involve  the  designation,  by  appropriate 
supervisory  personnel,  of  "protected  airspace"  around  busy 
traffic  flows  which  would  be  avoided  by  the  UPR.  Automation 
aids  also  may  be  introduced  to  help  establish  and  implement 
"preferred  routes"  to  avoid  the  high-density  areas. 

4.1.2  Dynamic  Airspace  Probe 

The  Airspace  Probe  function  is  expanded  in  AERA  1.02  to  detect 
conflicts  between  aircraft  trajectories  and  dynamic  airspace, 
primarily  heavy  weather  areas.  In  AERA  1.01,  the  Airspace 

Probe  predicted  conflicts  only  with  static  special  use  airspace 


and  terrain  protection  regions.  In  this  package,  the  probe  can 
detect  additional  possible  problem  areas  by  comparing  aircraft 
trajectories  with  forecasts  of  future  weather  patterns  made  by 
external  sources.  This  is  the  first  automated  tool  for  helping 
the  controller  to  predict  conflicts  between  aircraft  and 
weather  cells. 

The  current  methods  available  to  the  controller  for  identifying 
aircraft  encounters  with  weather  are  limited  due  to  lack  of 
current  weather  data  and  the  difficulty  of  predicting  future 
weather  patterns.  The  controller’s  knowledge  of  severe  weather 
areas  is  derived  mainly  from  pilot  reports  that  are  based  on 
visual  observations  and  on-board  weather  radar.  The  Air  Route 
Surveillance  Radar  is  designed  to  suppress  weather  information 
and  concentrate  on  aircraft  data.  The  Center  Weather  Service 
Unit  (CWSU)  gathers  and  analyzes  available  meteorological 
information,  but  the  dissemination  of  weather  data  and  expected 
forecasts  to  the  controllers  needs  improvement. 

The  brunt  of  responsibility  for  avoidance  of  weather  cells, 
icing,  and  turbulence  falls  on  the  pilot,  with  minimal 
assistance  from  the  controller.  The  controller’s  directives 
only  require  the  controller  to  assist  the  pilot,  where 
possible,  in  detection  and  avoidance  of  severe  weather  (see  Air 
Traffic  Controller’s  Handbook,  paragraphs  40,  50  [11]). 

In  AERA  1.02,  the  controller  is  in  an  improved  position  to 
assist  the  pilot  in  detecting  and  avoiding  severe  weather 
areas.  The  controller  will  have  available  for  relay  to  the 
pilot  detailed  information  concerning  the  weather  area,  such  as 
precipitation  levels,  wind  velocities,  and  turbulence  levels. 
This  information  is  provided  to  the  controller  by  the  NEXRAD 
(NEXt-generation  RADar)  system,  which  is  a  major  improvement  to 
the  ATC  system  to  be  implemented  prior  to  AERA  1.02.  The 
Dynamic  Airspace  Probe  allows  the  controller  to  provide  the 
pilot  with  advance  warning  of  encounters  with  severe  weather. 
With  the  detailed  weather  data  from  NEXRAD,  the  controller  will 
not  only  be  able  to  help  the  pilot  detect  possible  problem 
areas,  but  also  identify  effective  maneuvers  for  avoidance  of 
the  areas. 

NEXRAD  will  also  provide  data  to  the  CWSU  to  be  integrated  with 
other  weather  data  (e.g.,  from  the  National  Weather  Service) 
and  used  to  formulate  forecasts  of  future  weather  patterns  for 
the  center.  These  forecasts  will  be  available  from  the  CWSU 
and  Central  Weather  Processor  (CWp)  for  use  by  the  Dynamic 
Airspace  Probe. 
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4.1.3  Conflict-Free  Metering 


Among  the  major  features  of  AERA  1.02  la  the  generation  of 
conflict-free  metering  advisories.  When  an  aircraft  must  be 
delayed,  the  Metering  Planning  function  generates  a 
conflict-free  maneuver  for  the  aircraft  that  will  absorb  the 
required  amount  of  delay,  and  displays  this  information  to  the 
controller  in  an  advisory  message.  Should  the  advisory  be 
unacceptable  to  the  controller,  alternative  conflict-free 
advisories  are  available  on  request. 

It  is  important  to  understand  the  scope  of  the  term  ’'conflict- 
free"  as  it  applies  to  metering.  The  advisories  generated  by 
the  Metering  Planning  function  will  not  lead  to  conflicts  prior 
to  the  metering  fix  (i.e.,  the  geographic  point  which  the 
aircraft  is  to  cross  at  a  specified  time),  insofar  as  can  be 
determined  by  the  automated  probes.  The  segments  of  the 
aircraft’s  trajectory  before  the  start  of  the  maneuver  and 
after  the  maneuver  is  completed  are  not  guaranteed  to  be 
conflict-free  since  they  are  beyond  the  scope  of  Metering 
Planning.  (The  merging  of  the  Conflict  Resolution  function  and 
Metering  Planning  is  a  later  enhancement.)  Additionally, 
aircraft  not  considered  by  the  probes  (out-of-conformance,  VFR 
aircraft,  etc.)  are  not  taken  Into  account  by  Metering  Planning. 

Earlier  versions  of  the  metering  function  (ERM  I  and  ERM  II) 
provided  assistance  in  the  generation  of  an  initial  metering 
plan,  but  subsequent  tasks  of  probing  for  potential  conflicts 
within  the  plan  and  development  of  alternative  plans,  if 
necessary,  were  left  to  the  controller. 

The  Improvements  to  the  metering  function  In  AERA  1.02 
represent  a  major  step  toward  complete  automation  of  the 
controller’s  metering  activities.  Since  the  advisories  are 
conflict-free  (as  determined  by  the  probes)  and  recommend  an 
effective,  feasible  way  of  absorbing  the  required  delay  (based 
on  experience  gained  in  earlier  versions)  it  is  expected  that 
the  controller  will  accept  the  advisories  as  they  are 
presented.  In  this  case  only  the  transmittal  of  the  clearance 
to  the  pilot  remains  in  the  controller’s  domain,  and  in  future 
automation  packages  the  transmittal  will  also  be  automated.  If 
the  controller  determines,  for  a  reason  undiscemible  by  the 
probes,  that  the  advisory  is  unsatisfactory,  the  automated 
function  will  continue  to  provide  assistance  to  the  controller 
in  the  form  of  alternate  advisories. 
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A. 


4 . 1 . 4  Cont rolle r  Reminders 


To  maximize  the  validity  and  utility  of  the  automated  probes  of 
the  AAS,  it  is  essential  for  an  aircraft’s  trajectory,  which  is 
the  basis  for  all  of  the  probes,  to  reflect  the  most  current 
control  plan  for  the  aircraft.  In  AERA  1.02,  a  mechanism  for 
providing  additional  feedback  to  the  controller  about  the 
internal  version  of  the  control  plan  is  introduced  in  the  form 
of  Controller  Reminder  messages.  By  reminding  the  controller 
of  control  actions  that  he  had  planned  for  particular  aircraft, 
these  messages  help  the  controller  to  implement  the  previously 
agreed-to  plan,  or  to  identify  any  existing  differences  from 
the  controller’s  current  plan.  The  controller  may  then  update 
the  trajectory  for  the  aircraft  to  accurately  reflect  the 
current  plan. 

Strategic  control  plans  can  be  entered  into  the  computer  in  one 
of  two  ways  in  this  automation  package.  First,  certain  control 
actions,  such  as  descent  to  the  destination  airport,  are 
implied  by  an  aircraft’s  flight  plan  and  are  incorporated  into 
the  aircraft’s  trajectory  automatically  when  the  flight  plan  is 
initiated.  The  second  way  is  through  explicit  controller 
messages,  first  available  in  AERA  1.02,  that  allow  the 
controller  to  specify  a  control  action  to  be  Implemented  at 
some  known  time  in  the  future,  such  as  a  step  climb  to  a  new 
cruise  altitude,  but  which  is  not  part  of  the  aircraft’s 
current  clearance.  This  information  will  also  be  incorporated 
into  the  aircraft’s  trajectory  since  it  will  improve  the 
accuracy  of  the  trajectory  for  predicting  future  aircraft 
positions. 

The  major  significance  of  the  controller-entered  strategic 
Planned  Actions  and  the  Controller  Reminder  messages  is  the 
improvement  to  the  Trajectory  Estimation  function  and  thereby 
all  the  other  automation  functions  that  are  based  on  the 
trajectory.  The  more  detailed  knowledge  of  the  controller’s 
control  plan  for  an  aircraft  allows  the  aircraft’s  position  to 
be  more  accurately  predicted,  an  essential  input  for  valid  and 
effective  probes.  While  AERA  1.02  handles  only  planned 
altitude  changes,  future  automation  packages  will  deal  with 
additional  planned  actions,  to  eventually  include  all  actions 
related  to  control  of  aircraft. 

4.2  Functional  Description 

The  functional  components  of  AERA  1.02  and  their  interfaces  are 
depicted  in  Figure  4-1. 
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4.2.1  Trajectory  Estimation 

In  AERA  1.02,  Trajectory  Estimation  is  enhanced  to  include  the 

capability  to  model  goal-oriented  Metering  Planned  Actions 

i.e.,  planned  maneuvers  which  are  intended  to  deliver  the 

aircraft  to  a  given  location  at  a  given  time,  but  which  do  not 

completely  specify  how  that  goal  will  be  reached.  Thus,  in 

addition  to  the  four  planned  actions  already  supported  by 
Trajectory  Estimation  in  AERA  1.01,  the  following  new  ones  are 
added: 

•  Metered  descent 

•  Metering  vector 

•  Metering  speed  change 

In  addition  to  these  enhancements,  additional  aircraft 
performance  data  may  be  available  for  some  aircraft  by  direct 
downlink  from  the  aircraft  Flight  Management  Computer.  This 

additional  information  will  be  taken  into  account  when  the 

trajectory  is  modeled.  (It  should  be  noted  that,  while  the 

result  is  a  trajectory  which  more  closely  reflects  the  intent 
of  the  aircraft,  this  i9  the  result  of  better  data,  not  changes 
in  Trajectory  Estimation.) 

4. 2. 1.1  Execution  Stimuli 

As  in  AERA  1.01,  Trajectory  Estimation  is  activated  when  a  new 
or  revised  plan  is  received  from  the  Route  Conversion  function; 
the  controller  Inputs  a  plan  amendment;  or  the  Conformance 
Monitoring  function  indicates  the  need  for  resynchronization. 
Two  new  events  can  occur  in  AERA  1.02  that  will  also  trigger 
the  activation  of  Trajectory  Estimation: 

•  Metering  Planning  generates  one  or  more  Metering 
Planned  Actions  for  a  flight  and  requests  that  these 
planned  actions  be  incorporated,  into  the  trajectory. 

•  Trajectory  Estimation  is  called  to  update  a  trajectory 
to  reflect  updated  aircraft  performance  data. 

4.2. 1.2  External  Interfaces 

The  only  conceptual  change  in  external  interfaces  is  the 
updating  of  new  aircraft  performance  data  (which,  in  fact,  will 
probably  be  transparent  to  the  internal  processing  of 
|  Trajectory  Estimation).  This  new  performance  data,  downlinked 

|  from  the  aircraft,  consists  of  items  which  reflect  a  change  in 

! 
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the  manner  in  which  the  pilot  intends  to  follow  his  cleared 
plan  (e.g.,  a  different  climb  or  descent  gradient). 

An  example  of  this  would  be  a  new  gradient  or  speed  schedule  to 
be  used  for  a  particular  altitude  transition.  If  it  is  known 
in  advance  of  the  transition  that  a  gradient  other  than  the 
nominal  will  be  used,  the  incorporation  of  that  information 
into  the  trajectory  at  the  earliest  point  in  time  will  provide 
the  benefits  of  more  accurate  prediction  of  conflicts. 

The  other  external  interfaces  with  Trajectory  Estimation  are 
unchanged  from  AERA  1.01.  These  include  weather  information 
(winds  aloft,  temperatures  aloft),  adaptation  information 
applicable  to  the  Planning  Region  (for  example,  Standard 
Operating  Procedures  and  Letters  of  Agreement)  and  processed 
flight  plans  from  the  Route  Conversion  function  (both  new  plans 
and  existing  plans  with  route  amendments). 

A. 2. 1.3  Internal  Interfaces 

The  internal  interfaces  new  to  AERA  1.02  are  the  requests  for 
incorporation  of  Metering  Planned  Actions  into  the  aircraft 
trajectories  (from  the  Metering  Planning  function  of  the 
Solutions  Planning  component)  and  the  output  of  completed 
trajectories  to  the  Metering  Planning  and  the  Long  Range  Probe 
functions.  Other  internal  interfaces  from  AERA  1.01  remain 
unchanged:  the  output  of  trajectories  to  the  other  Problems 

Prediction  functions,  and  requests  from  Conformance  Monitoring 
to  resynchronize  a  trajectory. 

4.2.2  Problems  Prediction 

For  the  purpose  of  describing  the  system  in  terms  of  large, 
functional  areas,  it  is  convenient  to  group  together  several 
functions  in  the  category  of  "Problems  Prediction."  Three  of 
the  functions,  Flight  Plan  Conflict  Probe,  Airspace  Probe,  and 
Sector  Workload  Probe,  are  familiar  from  AERA  1.01.  Two 
additional  functions,  Long  Range  Probe  and  Metering  Prediction, 
are  included,  in  the  Problems  Prediction  area  for  AERA  1.02. 
Figure  4-2  illustrates  the  relationships  of  these  five  elements 
to  each  other  and  to  other  system  components. 

4. 2. 2.1  Execution  Stimuli 

Both  Flight  Plan  Conflict  Probe  and  Airspace  Probe  are 
activated  to  probe  for  conflicts  whenever  a  trajectory  is  first 
constructed  or  is  updated.  In  AERA  1.02,  the  probes  will  be 
activated  following  a  trajectory  update  requited  to  incorporate 
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PROBLEMS  PREDICTION  COMPONENT 


new  aircraft  performance  data,  such  as  downlinked  descent 
profile  information  for  a  particular  descent.  They  may  also  be 
called  upon  to  probe  a  trial  plan  formulated  by  Metering 
Planning, 

Airspace  probe  is  also  initiated  whenever  an  area  of  special 
use  airspace  is  activated  or  deactivated,  or  whenever  the 
definition  of  a  weather  area  is  added  or  updated  (e.g.,  the 
boundaries  of  the  area  change  or  the  predicted  velocity  is 
changed) . 

Metering  Prediction  is  activated  whenever  a  new  trajectory  is 
constructed  or  when  an  existing  trajectory  is  updated.  The 
Long  Range  Probe  is  activated  when  a  new  off-airway  flight  plan 
is  received  or  when  the  route  of  a  current  flight  plan  is 
amended  to  include  an  off-airway  segment.  The  Sector  Workload 
Probe  is  triggered  by  a  request  from  the  supervisor  for 
workload  information. 

4. 2, 2. 2  External  Interfaces 

The  functions  in  the  Problems  Prediction  area  have  a  number  of 
external  interfaces.  The  Long  Range  Probe  uses  information  on 
traffic  densities  and  preferred  routes  input  by  appropriate 
supervisory  personnel  at  the  center,  and  the  results  of  the 
probe  are  presented  to  the  controller.  The  Airspace  Probe 
requires  a  definition  of  the  weather  areas  and  special  use 
areas  that  must  be  provided  by  external  sources.  In  addition, 
the  output  from  both  Flight  Plan  Conflict  Probe  and  Airspace 
Probe  is  presented  to  the  controller  in  AERA  1.02  as  it  was  in 
AERA  1.01.  The  only  external  Interface  to  Metering  Prediction 
is  the  specification  of  the  metering  goals.  These  goals  will 
be  provided  by  such  sources  as  the  Flow  Controller  at  the  ACF 
or  a  neighboring  terminal  facility,  or  perhaps  by  the  sector 
controller.  The  goals  may  be  specified  in  one  of  the  following 
formats: 

•  arrival  rate  at  a  location  (where  ,,locationM  may  be  a 
fix  or  boundary) 

•  arrival  separation  at  a  location  (e.g.,  5  minutes 

apart,  or  25  miles  apart) 

•  a  specific  schedule  for  arrival  at  the  location 


4. 2. 2. 3  Internal  Interfaces 


All  five  of  the  Problems  Prediction  functions  utilize  the 
aircraft  trajectories  constructed  by  Trajectory  Estimation. 
These  trajectories  are  accessed  by  the  individual  functions  as 
required. 

The  Solutions  Planning  component  generates  a  request  to 
Metering  Prediction  to  determine  if  metering  is  required  for  a 
particular  plan.  If  it  is  necessary  to  insert  a  Metering 
Planned  Action  into  the  plan,  the  Flight  Plan  Conflict  Probe 
and  Airspace  Probe  are  requested  to  probe  a  trajectory  after  a 
Metering  Planned  Action  has  been  incorporated.  Since  that 
metering  plan  is  a  trial  plan  until  approved  by  the  controller, 
the  results  of  the  probes  are  returned  to  the  Solutions 
Planning  component  for  evaluation,  rather  than  being  presented 
to  the  controller. 

The  Solutions  Planning  component  also  generates  a  request  for 
the  Long  Range  Probe  to  examine  a  plan  for  possible  interaction 
with  areas  of  high  traffic  density,  or  with  ATC-pref  erred 
routes  (although  the  decision  to  incorporate  those  routes  is 
made  by  the  controller,  not  the  Solutions  Planning  functions). 

4.2.3  Solutions  Planning 

This  functional  area  represents  those  functions  which 
participate  in  the  process  of  planning  modifications  to  a 
strategic  flight  plan.  In  AERA  1.02,  we  see  the  first 
introduction  of  an  automatic  strategic  planning  function, 
Metering  Planning. 

Metering  Planning  will  meet  the  requirements  of  the  ERM  II 
package  which  was  used  in  AERA  1.01;  it  will  provide  arrival 
rate  metering  to  an  airport  and  metering  to  a  fix  (not  just 
meter  fixes)  or  boundary.  A  crucial  capability  added  in  AERA 
1.02  is  the  ability  to  integrate  the  metered  plan  with  the  AERA 
probes  and  thus  be  able  to  provide  the  controller  with 
"conf lict-free"  metering. 

Metering  Planning  is  intended  to  ensure  that  the  plans  of 
aircraft  requiring  metering  are  adjusted  with  the  appropriate 
planned  actions  to  absorb  the  required  delay  and  meet  the 
(externally  imposed)  metering  objectives.  The  delay  absorption 
tools  available  to  the  planner  are  the  new  goal-oriented 
planned  actions  and  the  "Hold"  Planned  Action  available  in  AERA 
1.01. 
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After  the  total  amount  of  delay  to  be  absorbed  by  a  flight  is 
determined  by  Metering  Prediction,  Metering  Planner  examines 
the  total  delay  and  decides  how  to  distribute  that  delay  over 
the  plan.  Typically,  several  maneuvers  are  used  to  absorb 
larger  amounts  of  delay.  For  example,  it  may  be  planned  for  an 
aircraft  to  execute  a  speed  reduction  to  Maximum  Endurance 
Speed  (MES),  followed  by  a  vector  to  absorb  more  delay,  and 
finally  meeting  the  total  required  delay  through  use  of  an  idle 
thrust  descent.  In  this  case,  these  ATC  actions  would  be 
represented  on  the  aircraft’s  trajectory  by  the  metered  speed, 
metering  vector  and  metered  descent  Planned  Actions. 

Having  decided  which  maneuvers  to  use  and  how  much  delay  they 
each  absorb,  Metering  Planning  then  addresses  the  first 
maneuver.  For  AERA  1.02,  Metering  Planning  deals  with  the 
maneuvers  one  at  a  time,  i.e.,  each  maneuver  is  modeled, 
ascertained  to  be  conflict-free,  and  sent  to  the  controller  for 
approval  and  execution  before  subsequent  maneuvers  are 
modeled.  Thus,  only  the  earliest  maneuver  is  modeled  (as  a 
trial  plan)  and  sent  to  the  conflict  probes  for  prediction  of 
conflicts.  If  conflicts  are  detected  in  the  selected  maneuver, 
the  parameters  of  that  planned  action  are  adjusted  or  another 
type  of  planned  action  is  selected.  After  adjusting  the 
planned  action,  the  plan  is  remodeled  and  again  examined  for 
conflicts.  This  continues  until  a  conflict-free  maneuver  is 
found  which  absorbs  the  delay  allocated  to  this  maneuver.  This 
Planned  Action  now  represents  the  candidate  metering  advisory. 
In  AERA  1.02,  metering  advisories  are  not  presented  to  the 
controller  until  it  is  near  the  time  to  actually  issue  the 

clearance(s)  to  the  aircraft,  so  Metering  Planning  does  not 
(necessarily)  immediately  notify  the  controller  of  the 
advisory.  When  it  is  time  to  notify  the  controller,  the  plan 
must  again  be  probed  for  conflicts,  since  other  plans  in  the 
system  may  have  changed,  affecting  the  plan  of  the  metering 
subject.  If  conflicts  are  detected  at  this  point,  the  entire 
process  of  maneuver  adjustment  must  be  repeated  until  a 

conflict-free  one  is  found.  When  the  planned  maneuver  is 
determined  to  be  conflict-free,  it  is  presented  to  the 

controller. 

When  the  maneuver  is  completed  by  the  aircraft,  Metering 

Planning  is  again  activated  to  repeat  the  process  with  the 
remaining  amount  of  delay  to  be  absorbed.  This  continues  until 
the  final  maneuver,  which  brings  the  aircraft  to  the  metering 
objective  by  the  proper  time. 


4.2. 3,1  Execution  Stimuli 


Whenever  a  new  flight  plan  is  received  or  an  existing  plan 
receives  an  amendment,  the  plan  is  checked  to  determine  if  the 
flight  requires  metering.  If  metering  is  required  for  that 
flight,  Metering  Planning  is  activated  to  determine  the  type  of 
maneuver  and  examine  the  results  of  incorporation  of  that 
maneuver  (to  ensure  conflict-free  manuevers,  if  possible). 
Metering  Planning  is  also  activated  whenever  the  metering  goals 
are  changed,  so  that  the  Metering  Planned  Actions  on  the  plan 
may  be  reevaluated.  In  addition,  it  will  be  triggered  by  a 
(longitudinal)  resynchronization.  New  arrival  times  created  by 
the  resynchronization  process  may  affect  delay  calculations, 
requiring  update,  replacement,  or  deletion  of  Metering  Planned 
Actions . 

In  addition  to  these  internal  triggering  events,  Metering 
Planning  may  be  invoked  as  a  consequence  of  the  controller’s 
rejection  of  a  presented  metering  advisory  in  order  to  try  a 
different  maneuver.  If  the  controller  requests  a  specific 
replacement  maneuver  with  specified  parameters,  Metering 
Planning  is  activated  to  evaluate  the  proposed  maneuver  and 
report  the  metering  consequences  to  the  controller. 

4. 2. 3. 2  External  Interfaces 

Metering  Planning’s  external  interfaces  are  with  the 
controller.  In  addition  to  the  output  to  the  controller  of  the 
probed  metering  advisory,  Metering  Planning  may  receive  a 
request  (from  the  controller)  to  try  a  metering  maneuver  other 
than  the  one  originally  presented.  The  new  maneuver  will  be 
incorporated  into  a  trial  plan  and  the  results  presented  to  the 
controller. 

4. 2. 3. 3  Internal  Interfaces 

Metering  Planning  utilizes  the  aircraft  trajectories  from 
Trajectory  Estimation  in  its  planning  processing.  Output  from 
the  planner  consists  of  requests  to  Trajectory  Estimation  to 
incorporate  the  generated  Planned  Action(s),  as  well  as 
requests  to  the  probe  functions  to  predict  problems  with  the 
new  Planned  Actions.  Results  from  the  probes  are  considered  by 
Metering  Planning  when  evaluating  the  effectiveness  of  a 
particular  maneuver  (before  presentation  of  that  maneuver  to 
the  controller  as  a  metering  advisory). 
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4 .2 .4  Plan  Implementation 

4. 2. 4.1  Conformance  Monitoring 

The  Conformance  Monitoring  function  within  the  Plan 
Implementation  functional  area  monitors  the  progress  of  each 
aircraft  with  respect  to  its  expected  trajectory  and  planned 
ATC  actions.  It  monitors  only  those  dimensions  (lateral, 
vertical,  speed,  time)  for  which  the  aircraft  is  not  executing 
a  maneuver.  (Tactical  Execution  will  monitor  the  maneuver 
dimensions.)  Prior  to  AERA  1.02,  significant  lateral  and 
vertical  deviations  from  the  trajectory  are  detected  and 
reported  to  the  controller;  longitudinal  deviations  are 
detected  and  passed  to  the  resynchronization  function  for 
automatic  processing.  Enhancements  for  AERA  1.02  consist  of 
monitoring  for  conformance  to  the  alrcraft9s  cleared  speed. 
Speed  deviations,  when  detected,  are  presented  to  the 
controller  for  evaluation  and  processing. 

4.2.4.1.1  Execution  Stimuli 


The  Conformance  Monitoring  component  is  activated  every 
tracking  cycle  to  monitor  for  conformance  of  the  aircraft's 
current  tracked  position  to  the  strategic  plan.  Each  tracking 
cycle,  new  radar  data  is  obtained  for  all  aircraft  in  the 
Planning  Region,  and  the  following  processing  is  then  performed. 

The  current  tracked  position  of  the  aircraft  is  compared  to  the 
expected  position  described  in  the  trajectory.  If  a  sufficient 
longitudinal  difference  is  detected,  the  resynchronization 
process  is  scheduled.  If  significant  deviations  in  another 
dimension  are  detected,  the  controller  is  notified  via  alert 
messages  (and  perhaps  also  by  other  means,  such  as 
out-of-confo  nance  indicators  in  the  data  block).  In  AERA 
1.02,  there  is  no  automatic  resolution  of  out-of-conformance 
conditions.  (If  the  deviation  is  large  enough,  the  controller 
may  feel  it  is  necessary  to  issue  a  new  clearance  to  the 
aircraft.  If  this  is  done,  a  plan  amendment  message  must  be 
entered  in  order  to  keep  the  trajectory  up  to  date  with  the  new 
clearance(s)  given  to  the  aircraft.)  The  Conformance 
Monitoring  function  continues  to  monitor  an  out-of -conformance 
aircraft  (although  no  more  messages  are  sent).  If  the  aircraft 
comes  back  into  conformance,  its  Internal  status  will  be 
changed  to  reflect  this. 

The  second  main  task  of  Conformance  Monitoring  is  to  monitor 
for  planned  action  starts.  The  trajectory  contains  indications 
of  when  processing  should  be  initiated  for  each  planned  action. 
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When  a  planned  action  start  indicator  is  detected  by  Conform¬ 
ance  Monitoring,  a  message  is  sent  to  the  Tactical  Execution 
(TEX)  function,  which  then  handles  the  processing  of  that 
planned  action.  From  this  point  until  processing  of  the 
planned  action  is  complete.  Conformance  Monitoring  performs 
association  checking  only  in  those  dimensions  not  being 
monitored  by  TEX.  When  processing  of  the  planned  action  is 
complete,  Conformance  Monitoring  is  activated  fully  by  receipt 
of  the  "Planned  Action  Complete"  message  sent  by  Tactical 
Execution. 

4. 2.4. 1.2  External  Interfaces 


New  track  data  for  each  aircraft  in  the  Planning  Region  is 
received  by  the  Conformance  Monitoring  function  from  the  Radar 
Processing  component  every  tracking  cycle. 

Output  from  this  component  consists  of  deviation  alert  messages 
to  the  controller  regarding  out-of-conformance  situations  in 
the  vertical,  lateral,  and  speed  dimensions. 

4. 2. 4. 1.3  Internal  Interfaces 

The  trajectory  constructed  by  Trajectory  Estimation  provides 
the  basis  for  the  comparison  of  tracked  location  vs.  predicted 
location  of  an  aircraft,  as  well  as  to  determine  when  it  is 
time  to  perform  a  previously-planned  planned  action. 
Conformance  Monitoring  also  sends  requests  to  Trajectory 
Estimation  to  resynchronize  a  trajectory.  In  addition, 
Conformance  Monitoring  notifies  Tactical  Execution  when  it  is 
time  to  perform  a  planned  maneuver  (in  the  case  of  AERA  1.02, 
the  only  previously  planned  maneuvers  are  altitude  changes  and 
metering  maneuvers),  and  Tactical  Execution,  in  turn,  notifies 
Conformance  Monitoring  when  a  maneuver  has  completed. 

4. 2. 4. 2  Tactical  Execution 


The  purpose  of  the  Tactical  Execution  function  is  to  process 
the  execution  of  planned  actions.  In  AERA  1.02,  this 
processing  consists  of  the  following: 

•  interaction  with  the  controller,  to  provide  notifica¬ 
tion  of  time  to  begin  an  Altitude  Planned  Action  and  to 
receive  feedback  from  the  controller  regarding  disposi¬ 
tion  of  the  planned  action  (approved/not  approved) 


•  monitoring  of  the  progress  of  the  aircraft  during 
execution  of  an  altitude  maneuver 


•  notification  (to  the  controller)  of  significant 
deviations  detected  during  the  altitude  maneuver 

4. 2 .4. 2.1  Execution  Stimuli 

TEX  begins  processing  a  planned  action  when  it  receives  a 
"Start  Planned  Action"  message  from  Conformance  Monitoring.  In 
AERA  1.02,  this  is  done  only  for  Altitude  Planned  Actions.  The 
initial  processing  begins  with  notifying  the  controller  of  the 
pending  planned  action  via  a  Controller  Reminder  message.  The 
controller  may  approve  further  processing  or  decide  against 
implementation  of  that  particular  planned  action.  (If  that 
planned  action  is  not  to  be  implemented,  the  controller  must 
enter  the  necessary  amendment  messaged)  to  keep  the  system 
apprised  of  his  intentions.)  Upon  receipt  of  controller 
approval.  Conformance  Monitoring  of  the  Altitude  Planned  Action 
begins.  On  each  tracking  cycle,  the  progress  of  the  aircraft 
is  compared  to  the  intent  of  the  planned  action.  Significant 
deviations  from  the  intent  (such  as  climbing  during  a  Descent 
Planned  Action  or  exceeding  the  assigned  target  altitude  on  a 
Climb  Planned  Action)  are  detected  and  an  alert  message  is  sent 
to  the  controller.  All  exception  handling  during  execution  of 
a  planned  action  in  AERA  1.02  Is  handled  by  the  controller. 

When  execution  of  the  planned  action  by  the  aircraft  is 
complete,  TEX  terminates  its  processing  by  sending  a  "Planned 
Action  Complete"  message  to  the  Conformance  Monitoring 
component,  which  will  then  resume  its  own  monitoring  of  the 
aircraft. 

4. 2 .4. 2. 2  External  Interfaces 

Tactical  Execution  receives  track  data  from  the  Radar  Data 
Processing  function  to  be  used  in  monitoring  for  conformance  to 
the  altitude  transition  profile  and  in  determining  when  the 
maneuver  is  completed. 

It  also  provides  several  types  of  information  to  the 
controller:  "reminders"  that  a  previously  planned  maneuver  was 
expected  to  begin  now  (for  AERA  1.02,  the  maneuver  would  be  an 
altitude  transition)  and  deviation  alerts  (for  AERA  1.02,  only 
deviations  from  the  vertical  profile  are  detected).  Responses 
from  the  controller  regarding  approval  or  rejection  of  these 
reminders  are  also  received  by  TEX. 


4.2.4 .2* 3  Internal  Interfaces 


Tactical  Execution  receives  notification  from  the  Conformance 
Monitoring  function  that  a  maneuver  was  planned  to  begin  at  the 
current  time,  and,  upon  completion  of  that  maneuver,  a  message 
is  sent  to  Conformance  Monitoring  informing  it  of  the 
completion. 

Although  TEX  does  not  use  the  trajectory  as  the  conformance 
goal,  it  does  use  a  description  of  the  Altitude  Planned  Action 
in  determining  conformance  to  the  intent  of  the  planned  action. 

4.2.5  Tactical  Problem  Detection 


The  basic  purpose  of  this  component  remains  unchanged  from  the 
Conflict  Alert  and  MSAW  function  of  the  current  NAS  system:  to 
continually  monitor  the  actual  tracked  positions  of  aircraft  in 
the  Planning  Region  to  detect  imminent  conflicts.  For  AERA 
1.02,  two  enhancements  are  added  to  the  capabilities  of  this 
function:  track  information  Is  supplemented  with  downlinked 

flight  performance  data  (via  Mode  S),  and  imminent  conflicts 
with  dynamic  airspace  (weather)  are  detected.  These  enhanced 
functions  will  be  referred  to  as  Separation  Assurance 
Monitoring  and  Airspace  Violation  Detection,  respectively. 

The  downlinked  flight  performance  data  referred  to  here 
provides  more  Immediate  and  more  detailed  information  about  the 
current  state  of  the  aircraft.  An  example  of  this  would  be 
such  information  as  an  Indication  from  the  aircraft  that  it  is 
executing  a  turn.  Receipt  of  this  "turn  indicator"  provides 
Tactical  Problem  Detection  with  more  immediate  information 
about  the  current  state  of  the  aircraft  than  would  have  been 
obtained  from  track  data  alone  (since  the  radar  processing 
function  will  smooth  out  the  radar  returns  before  reporting 
that  the  aircraft  is  actually  turning). 

Processing  within  the  Tactical  Problem  Detection  component  is 
functionally  much  the  same  as  in  today's  system.  The  expected, 
near-term  flight  path  of  an  aircraft  is  projected  forward  in 
time  from  the  current  tracked  position,  using  the  current 
velocity  of  the  aircraft.  The  projected  flight  paths  of  all 
aircraft  in  the  center  are  compared  with  each  other  in  a 
pairwise  fashion  to  determine  if  any  of  the  pairs  will  violate 
separation  minima.  The  flight  paths  are  also  checked  for 
near-term  intersection  with  predefined  areas  of  special  use 
airspace  and  heavy  weather  areas.  When  a  conflict  is 
predicted,  the  Tactical  Problem  Resolution  component  generates 


a  set  of  alternative  resolutions  (Conflict  Resolution  Adviso¬ 
ries,  introduced  prior  to  the  AAS)  which  are  presented  to  the 
applicable  sector  controller  along  with  identification  of  the 
conflict. 

4. 2. 5.1  Execution  Stimuli 

The  Tactical  Problem  Detection  component  is  activated  only  by 
the  receipt  (from  the  Radar  Data  Processing  function),  on  each 
tracking  cycle,  of  new  track  data  for  each  of  the  aircraft  in 
the  Planning  Region. 

4. 2. 5. 2  External  Interfaces 

The  new  track  data  for  each  aircraft  is  received  from  a  source 
external  to  the  AERA  functions  (from  the  Radar  Data  Processing 
function),  and  this  information  is  supplemented  with  downlinked 
performance  data,  if  the  aircraft  is  equipped  with  Mode  S  and 
other  appropriate  equipment.  In  addition,  Airspace  Violation 
Detection  uses  predetermined  definitions  of  heavy  weather  areas 
and  areas  of  special  use  airspace  (stored  in  the  system  data 
base) • 

The  results  of  the  processing  (notifications  of  predicted 
near-term  conflicts  between  aircraft  pairs,  between  aircraft 
and  airspace  areas,  or  between  aircraft  and  weather  areas)  are 
reported  to  the  applicable  sector  controller. 

4. 2. 5. 3  Internal  Interfaces 

Tactical  Problem  Detection  results  are  not  used  by  any  of  the 
other  major  AERA-related  components  except  Tactical  Problem 
Resolution,  and  Tactical  Problem  Detection  does  not  itself  use 
any  information  from  those  components. 

4.2.6  Tactical  Problem  Resolution 

No  enhancement  in  this  area  occurs  in  AERA  1.02.  As  in  AERA 
1.01,  Conflict  Resolution  Advisories  are  generated  upon 
detection  of  an  aircraft  or  airspace  conflict  by  Tactical 
Problem  Detection,  and  the  advisories  are  presented  to  the 
controller  for  evaluation  and  selection. 


4.3  Operational  Description 

4.3.1  Long  Range  Probe 

4. 3. 1.1  Stimulus 

There  are  three  ways  In  which  the  Long  Range  Probe  can  be 
invoked.  The  principal  method  is  through  a  Trial  Plan  Probe  in 
which  the  controller  proposes  a  User-Preferred  Route.  In  this 
case,  the  Long  Range  Probe  is  run  along  with  FPCP  and  AP,  and 
its  results  are  displayed  simultaneously.  The  Long  Range  Probe 
is  also  invoked  when  a  flight  plan  amendment  containing  an 
off-airway  route  segment  is  entered  by  the  controller. 

The  third  situation  in  which  the  Long  Range  Probe  is  invoked  is 
when  the  information  on  areas  of  high  traffic  density,  or  ATC- 
preferred  routes,  is  changed.  This  information  may  be  updated 
by  a  supervisor-level  controller,  such  as  the  Area  Supervisor 
or  the  Plow  Controller,  based  on  input  from  the  AERA  data  base 
and  other  automated  aids.  Alternatively,  this  information  may 
be  updated  automatically.  When  the  updating  occurs,  all 
affected  flights  are  reconsidered  by  the  probe,  and  the 
controller  Is  notified  of  any  detected  problems. 

4. 3. 1.2  Information  Displayed 

The  message  to  the  controller  contains  the  nature  and  location 
of  the  detected  problem.  The  results  of  the  Long  Range  Probe 
are  displayed  to  the  controller  on  the  Alert  and  Resolution 
logical  display.  If  the  probe  was  invoked  within  the  Trial 
Plan  Probe  tool,  the  results  are  presented  along  with  the 
results  from  the  other  automated  probes.  If  the  origin  of  the 
probe  was  a  flight  plan  amendment  or  change  in  status  of  a 
preferred  route,  the  information  is  displayed  in  a  separate 
message  to  the  controller  on  the  same  display. 

4. 3. 1.3  Controller’s  Response 

Since  preferred  route  segments,  when  applicable,  are  required 
to  be  Included  in  the  flight  plan,  the  controller  must  either 
Include  the  applicable  segment  of  an  ATC-preferred  route  in  the 
flight  plan  or  retract  the  proposed  amendment.  Both  of  these 
options  are  available  on  the  interactive  display. 

The  decision  of  how  to  handle  an  interception  with  a  high 
traffic  density  area  is  left  to  the  controller,  who  may  modify 
the  planned  route,  coordinate  with  the  involved  controller,  or 
defer  resolution.  The  message  from  the  Long  Range  Probe  serves 
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only  as  notification  to  the  controller  of  the  high  density  area. 


4.3.2  Dynamic  Airspace  Probe 
4 . 3 .2.1  Stliiulu8 


The  Dynamic  Airspace  Probe  will  alert  the  controller  to 
situations  in  which  an  aircraft's  trajectory  is  predicted  to 
intercept  a  defined  hazardous  weather  area.  The  alert  is 
analogous  to  the  alert  for  a  conflict  with  a  static  special  use 
airspace  except  that  the  look-ahead  time  used  by  the  probe  may 
be  significantly  shorter  due  to  the  volatile  nature  of  weather 
areas  and  the  associated  difficulty  in  forecasting  future 
patterns  and  positions  of  the  areas.  Whereas  conflicts  with 
static  airspaces  can  be  detected  across  an  entire  center, 
conflicts  with  dynamic  airspaces  may  be  reliably  detected  only 
across  one  or  two  sectors. 

4. 3. 2. 2  Information  Displayed 

Advisory  and  priority  messages  about  predicted  conflicts  with  a 
hazardous  weather  area  will  be  displayed  to  the  controller, 
perhaps  on  the  Alert  and  Resolution  logical  display.  The 
messages  will  contain  information  to  identify  the  conflict, 
such  as  aircraft  ID,  location  of  predicted  interception,  and 
time  of  predicted  interception.  Additional  information  will  be 
available  on  controller  request  and  may  be  presented  on  the 
Planning  Display.  The  additional  information  will  include  data 
that  might  be  useful  to  the  controller  or  pilot  in  determining 
how  to  avoid  the  weather  area,  such  as  location  and  extent  of 
the  weather  area,  type  of  weather,  and  rate  and  direction  of 
movement  of  the  area.  A  graphical  display  may  be  an  effective 
way  to  portray  this  information. 

As  with  conflicts  involving  static  special  use  airspace,  if  the 
interception  with  a  dynamic  airspace  is  predicted  to  occur  in 
the  sector  in  which  the  aircraft  is  currently  flying,  a 
priority  message  is  sent  to  the  controller  of  that  sector.  The 
priority  message  conveys  the  imminence  and  severity  of  the 
situation  and  warns  that  the  aircraft  should  take  immediate 
action  to  avoid  the  encounter.  If,  however,  the  interception 
is  predicted  to  occur  in  a  sector  other  than  the  one  in  which 
the  aircraft  is  currently  flying,  the  controller  currently  In 
control  of  the  aircraft  will  be  informed  of  the  situation  via 
an  advisory  message.  The  rationale  behind  the  advisory  message 
for  an  encounter  with  dynamic  airspace  differs  from  that  for  an 
encounter  with  static  airspace.  Rather  than  signifying  that 
he  interception  is  relatively  certain  to  occur  but  is  not 


cine-critical  to  resolve ,  encounters  with  weather  can  not  be 
predicted  with  certainty,  but  warrant  attention  since  they  can 
quickly  develop  into  more  serious  situations.  In  this  way  they 
are  similar  to  conflicts  between  aircraft.  The  advisory 
message  indicates  that  immediate  action  is  not  required  on  the 
part  of  the  controller,  but  that  this  is  a  situation  of  which 
the  controller  and  the  pilot  may  want  to  be  aware  for  planning 
purposes . 

4*3.2 .3  Controller's  Response 

The  primary  use  of  the  priority  or  advisory  message  is  as  an 
Information  source  for  informing  the  pilot  of  impending 
situations.  In  the  current  system,  and  likely  in  AERA  1.02, 

the  controller  is  not  required  to  guarantee  separation  of 

controlled  aircraft  from  severe  weather  areas.  Rather,  the 
controller  is  directed  to  inform  pilots  of  identified  weather 
areas  and,  if  requested,  to  assist  the  pilot  in  avoiding  the 
areas.  As  described  in  Section  4.1.2,  Dynamic  Airspace  Probe, 
the  controller’s  lack  of  information  is  related  to  his  limited 
responsibilities  in  dealing  with  severe  weather.  In  AERA  1.02 
the  controller  will  be  better  able  to  assist  the  pilot  in 

avoiding  areas  of  weather  because  of  the  additional  data 

available  in  the  priority  and  advisory  messages  and  on  the 
associated  displays. 

4.3.3  Conflict-Free  Metering 

4. 3.3.1  Stimulus 

When  an  aircraft  must  be  metered,  as  determined  by  the  metering 
function,  a  conflict-free  metering  advisory  is  generated  for 
display  to  the  controller.  The  advisory  is  displayed  to  the 
controller  a  specified  (system  parameter)  time  before  it  must 
be  issued  to  the  pilot  to  allow  the  controller  time  to  revise 
the  advisory,  if  necessary,  before  it  must  be  transmitted  to 
the  aircraft  (see  Section  4.3 .3 .3,  Controller's  Response). 

4. 3. 3. 2  Information  Displayed 

The  metering  advisory  is  displayed  to  the  controller  in  the 
form  of  a  message  on  the  Metering  Advisory  List  logical 
display,  containing  the  information  needed  to  issue  a  clearance 
to  the  pilot  to  execute  the  maneuver.  Such  Information 
includes  the  aircraft  to  be  metered,  the  type  of  maneuver  and 
the  specific  parameters  for  the  maneuver  (speed,  descent  point, 
descent  rate,  radar  vector  heading,  time  in  hold,  etc.).  The 
controller  is  also  informed  of  the  amount  of  delay  to  be 


absorbed  and  the  goal  to  be  accomplished  (the  time  the  aircraft 
should  cross  the  fix  or  boundary)  so  that,  If  need  be,  an 
alternative  advisory  can  be  formulated. 


To  help  the  controller  plan  ahead,  some  relevant  metering 
information  could  be  presented  on  the  Flight  Data  Display.  For 
aircraft  to  be  metered,  the  amount  of  delay  to  be  absorbed  and 
the  type  of  maneuver  being  planned  by  the  metering  function 
(metered  descent,  speed,  hold,  vector)  may  be  Included  in  the 
display.  This  data  would  be  displayed  before  the  metering 
advisory  is  given  to  the  controller  to  allow  the  controller  to 
plan  ahead  and  Integrate  the  metering  tasks  with  other  control 
tasks.  This  data  would  be  updated  as  required. 

4. 3. 3. 3  Controller's  Response 

The  controller's  decision  as  to  whether  or  not  to  Implement  a 
metering  advisory  will  be  based  primarily  on  a  mental  check  for 
potential  conflicts  that  could  not  be  detected  by  the  automated 
probes  (e.g.,  those  with  out-of-conformance  aircraft,  VFR 
aircraft,  etc.).  While  the  advisory  proposes  an  effective  way 
of  metering  the  aircraft  as  far  as  the  automated  probes  can 
determine,  the  controller  may  have  additional  relevant 
information  and  is  free  to  accept  or  reject  the  advisory  based 
on  his  own  knowledge  and  expertise.  The  display  of  the 
advisory  is  timed  to  allow  the  controller  sufficient  time  to 
check  for  potential  conflicts  and  formulate  an  alternative 
clearance  if  necessary.  However,  the  advisory  is  presented 
close  enough  to  the  implementation  time  to  be  able  to  take 
advantage  of  the  latest  estimate  of  delay  required. 

If  the  controller  decides  to  accept  the  advisory,  the 
controller  transmits  the  new  clearance  containing  the  metering 
maneuver  to  the  pilot,  receives  an  acknowledgment,  and 
indicates  to  the  computer  that  the  advisory  has  been  accepted. 
The  details  of  the  flight  plan  amendment  need  not  be  entered, 
since  they  are  already  available  through  the  metering  function. 

At  this  point,  the  aircraft's  flight  plan  is  amended  to  Include 
the  metering  maneuver,  and  the  aircraft's  trajectory  is 
remodeled  as  necessary  to  reflect  the  change.  The  remodeling 
triggers  the  FPCP  and  AP  to  be  run  on  the  new  trajectory. 
Normally  no  new  conflicts  will  be  detected  since  the  metering 
advisory  was  already  tested  for  conflicts  before  it  was 
displayed  to  the  controller.  However,  if  there  was  a  delay 
between  the  time  the  advisory  was  Issued  and  the  time  it  was 
accepted,  a  change  to  another  aircraft's  trajectory  may  have 
resulted  In  a  conflict  which  could  not  have  been  detected 
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previously*  The  controller  resolves  these  new  conflicts  as  any 
other  conflicts  are  resolved*  It  Is  expected  that  In  most 
cases  no  new  conflicts  will  develop  when  the  advisory  is 
implemented* 

If  the  controller  decides  to  reject  the  computer-generated 
advisory  (most  likely  because  of  conflicts  with  aircraft  that 
are  not  considered  by  the  probes),  the  metering  function  will 
provide,  on  controller  request,  additional  advisories  that  will 
allow  the  aircraft  to  meet  the  metering  goal  in  a  conflict-free 
manner.  If  desired,  the  type  of  maneuver  to  be  employed  can  be 
specified*  To  do  this,  the  controller  might  request  a  list  of 
the  maneuvers  that  the  metering  function  can  consider,  and 
select  a  particular  maneuver  from  this  list.  Alternatively, 
the  controller  could  enter  a  trial  amendment  which  reflects  the 
desired  maneuver* 

The  metering  function  will  attempt  to  absorb  the  required  delay 
in  a  conflict-free  manner  with  the  specified  maneuver.  If  the 
attempt  is  successful,  the  advisory  will  be  presented  to  the 
controller,  who  may  accept  and  implement  it  using  the  procedure 
described  above* 

If  only  part  of  the  delay  can  be  absorbed  by  the  specified 
maneuver,  the  controller  is  informed  of  the  amount  of  delay 
remaining  and  may  accept  and  Implement  the  advisory,  thereby 
absorbing  part  of  the  delay.  The  remaining  delay  will  be 
absorbed  by  subsequent  maneuvers  planned  by  the  metering 
function* 

If  the  specified  maneuver  is  infeasible,  due  to  traffic  or 
insufficient  time  to  effect  the  maneuver,  the  controller  is  so 
Informed  and  must  select  another  maneuver  to  meter  the  aircraft* 

4*3*4  Controller  Reminders 

4.3.4.1  Stimulus 


The  controller  is  notified  of  impending  planned  altitude 
changes  in  the  trajectory  by  controller  reminder  messages  that 
are  displayed  at  the  planned  start-of-transition  point.  The 
planned  altitude  changes  can  originate  either  through  explicit 
controller  action  or  through  normal  flight  plan  initiation. 

The  messages  for  certain  planned  altitude  changes  implicit  In 
the  flight  plan  may  be  inhibited  in  adaptation,  so  that  the 
reminders  are  useful  to  the  controller  and  not  a  nuisance.  An 
example  of  such  a  situation  is  the  normal  descent  route  into  a 
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major  airport.  Since  the  controller  handles  many  aircraft 
along  this  route  every  hour,  a  reminder  on  each  one  telling 
when  the  aircraft  is  to  descend  may  not  be  needed.  In  this 
case,  the  reminders  for  aircraft  arriving  at  this  airport  might 
be  inhibited.  On  the  other  hand,  if  an  aircraft  is  planned  to 
descend  to  an  infrequently-used  airport,  a  controller  reminder 
at  the  top-of-descent  point  may  be  useful  and  would  therefore 
be  presented. 

4. 3.4.2  Information  Displayed 

Included  in  the  reminder  message,  which  is  displayed  on  the 
Alert  and  Resolution  logical  display,  are  the  details  of  the 
planned  altitude  change,  such  as  the  aircraft  involved,  the  new 
altitude,  and  any  restrictions  incorporated  in  the  plan.  If 
the  controller  explicitly  planned  the  altitude  change,  all  of 
this  information  would  have  been  entered  at  that  time.  If  the 
altitude  change  was  deduced  from  the  flight  plan,  the  data  is 
extracted  from  the  flight  plan  and  pertinent  Letters  of 
Agreement  and  facility  Standard  Operating  Procedures. 

4. 3. 4. 3  Controller's  Response 

At  the  time  a  reminder  message  is  displayed,  the  controller  has 
the  option  to  either  issue  the  altitude  change  as  planned  or 
alter  the  plan  by  either  issuing  a  different  clearance  or 
leaving  the  aircrafts  current  clearance  in  effect. 

Most  likely,  the  controller  will  issue  the  altitude  change  as 
planned,  in  which  case  the  controller  transmits  the  clearance, 
receives  an  acknowledgment,  and  Indicates  to  the  computer  that 
the  plan  has  been  Implemented.  The  flight  plan  amendment  need 
not  be  entered  explicitly  since  the  information  is  already 
included  in  the  trajectory. 

If  the  controller  decides  not  to  issue  the  clearance  as 
planned,  it  will  be  necessary  to  update  the  aircraft's  current 
plan,  which  had  contained  the  planned  action  which  triggered 
the  reminder.  Failure  to  make  the  update  would  result  in  the 
aircraft  being  out  of  conformance  with  its  trajectory,  in  which 
case  an  out-of -conformance  alert  for  the  aircraft  would  be 
presented  to  the  controller,  warning  of  the  situation  that  had 
developed.  Exactly  how  the  aircraft's  trajectory  would  be 
modeled  in  this  situation  is  currently  an  open  issue.  The 
options  being  considered  include  stopping  the  trajectory 
modeling  since  the  controller's  intent  is  unknown,  or  making 
some  facilitating  assumptions  about  intent  and  approximating  a 
reasonable  estimate  of  the  trajectory. 
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5.  AERA  2,01 


AERA  2.01  is  the  first  in  a  series  of  packages,  known  as  AERA 
2,  to  offer  the  controller  assistance  in  resolving  problems 
detected  by  the  advanced  automation  functions.  In  this  pack¬ 
age,  the  assistance  is  in  the  form  of  general  advisories,  while 
subsequent  packages  will  provide  more  detailed  information  on 
specific  resolutions.  The  following  enhancements  are  discussed 
below:  General  Resolution  Advisories,  Multiple-Step  Metering, 
and  other  improvements.  In  addition,  the  functions  introduced 
in  AERA  1  are  expected  to  undergo  incremental  improvement. 

5.1  Enhancement  Features 


5.1.1  General  Resolution  Advisories 

The  purpose  of  the  new  resolution  function  in  AERA  2.01  is  to 
assist  the  controller  in  arriving  at  resolutions  for  those 
conflicts  which  justify  resolution  processing.  Long-range 
conflicts  with  a  lower  probability  of  resulting  in  a  separation 
violation  may  not  be  reasonable  candidates  for  resolution.  The 
criteria  for  distinguishing  between  resolution  candidates  and 
non-candidates  is  an  issue  requiring  further  discussion. 

In  AERA  2.01,  the  dynamic  resolution  of  conflicts  is  applied 
only  to  aircraft-aircraft  conflicts.  Dynamic  resolution  of 
conflicts  with  volumes  of  airspace  or  weather  areas  is  reserved 
until  later  steps. 

For  each  candidate  aircraft  conflict  detected  by  FPCP,  the 
system  will  generate  several  general  resolution  advisories 
which  indicate  alternative  types  of  maneuvers  that  would  be 
effective  in  resolving  the  conflict  situation.  The  particular 
parameters  of  a  maneuver  (e.g.,  specific  speed,  altitude,  vec¬ 
tor  heading,  etc.)  are  not  provided  by  the  system,  but  would  be 
furnished  by  the  controller  should  the  advisory  be  accepted. 
Once  an  advisory  has  been  accepted  and.  the  specific  parameters 
identified,  the  Trajectory  Estimation  function  determines  the 
s tart-of -maneuver  point. 

For  airspace  conflicts  detected  by  Airspace  Probe,  the  system 
will  produce  resolution  advisories  which  indicate  the  desig¬ 
nated  preferred  routes  or  Severe  Weather  Avoidance  Plan  (SWAP) 
routes  for  avoiding  the  airspace.  The  controller,  should  he 
decide  to  implement  one  of  these  advisories,  is  responsible  for 
directing  the  aircraft  to  and  from  the  identified  routes. 
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The  eveatual  goal  of  the  automation  effort  is  to  have  automa¬ 
tion  functions  recognize  conflict  situations  and  Identify  the 
best  resolution  strategy  in  terms  of  maximizing  system  safety , 
minimizing  adverse  impact  on  aircraft  and,  to  the  extent 
possible,  on  controller  workload.  In  the  AERA  2  packages  (AERA 
2.01,  2.02,  2.03),  the  Conflict  Resolution  Planning  function  is 
added  to  the  automation  system  and  is  first  apparent  to  the 
controller  in  the  form  of  general  resolution  advisories  in  AERA 
2.01.  Improved  conflict  resolution  aids  that  provide  more 
detailed  information  to  the  controller  on  effective  resolution 
strategies  evolve  from  the  general  advisories  function  and  are 
available  to  the  controller  in  AERA  2.02  and  AERA  2.03. 

5.1.2  Multiple-Step  Metering 

In  AERA  2.01,  a  multiple-step  plan  for  metering  aircraft  is 
formulated  and  presented  to  the  controller  for  approval  before 
any  of  the  steps  are  implemented.  The  controller  may  accept 
all  or  part  of  the  metering  plan  as  it  is  presented.  The 
accepted  plan  is  incorporated  into  the  aircraft’s  trajectory, 
and  the  controller  is  notified  via  Controller  Reminder  messages 
when  it  is  time  to  issue  the  clearances  to  the  aircraft. 

In  previous  versions  of  the  Metering  Planning  function,  though 
several  maneuvers  were  implemented  to  absorb  the  entire  delay, 
only  one  maneuver  was  presented  to  the  controller  at  a  time, 
and  that  one  not  until  it  was  time  to  implement  the  maneuver. 
The  maneuvers  were  incorporated  into  the  trajectory  only  as  the 
controller  implemented  them,  and  since  each  maneuver  absorbed 
only  part  of  the  delay,  the  trajectory  was  not  completely 
current  with  the  known  metering  plan  while  there  was  still 
delay  to  be  absorbed. 

The  principal  benefit  of  the  multiple-step  metering  plan  is 
expected  to  be  that  the  controller  can  accept  the  whole  plan  at 
once,  thereby  allowing  the  trajectory  to  be  complete  and  cur¬ 
rent.  Additionally,  the  controller  can  be  aware  of  upcoming 
maneuvers  that  the  aircraft  will  make  and  can  formulate  control 
plans  accordingly. 

5.1.3  Other  Enhancements 


The  use  and  capability  of  data  link  will  be  greatly  expanded  in 
AERA  2.01.  The  primary  capability  that  affects  the  operation 
of  the  ATC  system  is  that  non-control  messages  (requests  for 
weather  information,  terminal  configurations,  etc.)  can  be 
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handled  without  controller  intervention*  Requests  for  informa¬ 
tion  are  downlinked  directly  to  the  ground-based  computer  and 
are  received,  processed,  and  responded  to  without  any  action 
necessary  on  the  part  of  the  controller.  The  requested  infor¬ 
mation  la  relayed  to  the  aircraft  via  data  link.  This  automa¬ 
tion  frees  the  controller  to  concentrate  on  actions  which 
require  his  skill  and  judgment. 

Another  enhancement  in  AERA  2.01  is  that  the  Controller  Remind¬ 
er  messages  are  expanded  to  cover  planned  actions  for  conflict 
resolution.  The  Conflict  Resolution  Planning  function  may 
generate  an  advisory  that  contains  maneuvers  that  are  to  be 
implemented  at  some  specified  time  in  the  future.  If  the 
controller  accepts  the  advisory,  the  maneuvers  are  automat¬ 
ically  Incorporated  into  the  aircraft's  trajectory,  and  the 
Controller  Reminder  messages  will  be  displayed  at  the  appropri¬ 
ate  time  to  notify  the  controller  when  the  planned  maneuvers 
are  to  be  implemented.  The  ability  to  specify  planned  actions 
for  conflict  resolution  strategies  helps  to  maintain  the 
integrity  of  aircraft  trajectories. 

5.2  Functional  Description 

Figure  5-1  illustrates  the  primary  internal  interfaces  between 
these  AERA  2.01  components.  A  more  detailed  description  of  the 
interfaces  (both  external  and  internal),  as  well  as  a  descrip¬ 
tion  of  the  relative  processing  sequence  of  the  components  is 
provided  in  the  following  paragraphs. 

5.2.1  Trajectory  Estimation 

As  in  AERA  1.02,  the  purpose  of  Trajectory  Estimation  has  not 
changed  from  previous  steps,  but  an  important  enhancement  has 
been  added;  the  ability  to  model  goal-oriented  Resolution 
Planned  Actions.  This  feature  allows  the  Solutions  Planning 
component  to  specify  a  particular  type  of  maneuver  to  resolve  a 
conflict,  using  one  of  the  following  Planned  Actions: 

•  Resolution  vector 

•  Altitude  for  resolution 

•  Hold  (available  in  AERA  1.01) 

•  Speed  for  resolution 

5.2. 1.1  Execution  Stimuli 

The  only  change  to  the  list  of  events  which  trigger  the 
activation  of  Trajectory  Estimation  is  the  addition  of  the 
request  from  the  Conflict  Resolution  Planning  function  (of  the 
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Solutions  Planning  component)  to  incorporate  a  Resolution 
Planned  Action.  All  other  stimuli  remain  the  same:  Trajectory 
Estimation  is  activated  to  construct  a  new  trajectory  for  a 
newly  received  flight  plan  or  to  update  an  existing  plan. 

5. 2. 1.2  Interfaces 

No  new  external  interfaces  are  added  in  AERA  2.01,  and  the  only 
new  Internal  interface  is  the  addition  of  the  request  from 
Conflict  Resolution  Planning  to  incorporate  the  Resolution 
Planned  Actions. 

5.2.2  Problems  Prediction 

In  AERA  2.01,  no  functional  changes  are  made  to  the  elements  of 
Problems  Prediction.  Sector  Workload  Probe,  Long  Range  Probe, 
Airspace  Probe,  Flight  Plan  Conflict  Probe,  and  Metering 
Prediction  each  have  the  same  functional  capabilities  and  basic 
processing  sequences  as  described  for  AERA  1.02. 

5. 2. 2.1  Execution  Stimuli 

With  the  exception  of  Sector  Workload  Probe,  which  is  driven  by 
requests  from  a  supervisor,  the  functions  in  Problems  Predic¬ 
tion  are  activated  whenever  a  new  trajectory  is  constructed  or 
an  existing  one  is  modified.  That  does  not  change  in  AERA 
2.01,  although  there  are  new  reasons  for  the  modification  of 
trajectories:  planned  actions  generated  by  the  Conflict 
Resolution  Planning  function  will  be  incorporated  in  the 
trajectories,  and  the  Problems  Prediction  functions  will  be 
initiated  to  probe  for  conflicts. 

5 . 2 . 2 . 2  Interfaces 

There  are  no  changes  in  external  interfaces  with  the  Problems 
Prediction  functions,  and  the  only  difference  in  internal 
interfaces  is  the  feedback  of  conflict  information  to  the 
Conflict  Resolution  Planning  function. 

5.2.3  Solutions  Planning 

In  AERA  2.01,  in  addition  to  maintaining  Metering  Planning,  the 
strategic  Solutions  Planning  component  gains  a  very  important 
enhancement  In  the  form  of  the  Conflict  Resolution  Planning 
function.  It  should  be  stressed  that  this  function  is  a 
strategic  function,  not  to  be  confused  with  the  resolution 
capability  in  the  Tactical  Problem  Resolution  component. 
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5.2. 3.1  Conflict  Resolution  Planning 

The  resolution  of  aircraft-aircraft  conflicts  in  AERA  2.01  is  a 
rudimentary  version  of  dynamic  conflict  resolution,  in  that  an 
interactive  conversation  with  the  controller  is  maintained  in 
order  to  obtain  specific  parameters  of  the  resolution.  (In 
later  AERA  steps,  the  Conflict  Resolution  Planning  function 
itself  determines  the  parameters  of  the  resolution  maneuvers.) 

The  first  processing  step  that  Conflict  Resolution  Planning 
takes  is  to  decide  which  conflicts  are  candidates  for  resolu¬ 
tion.  Having  decided  upon  a  conflict  to  resolve,  the  function 
selects  (based  upon  a  predetermined  set  of  rules)  the  type  of 
Planned  Action  to  be  used  In  avoiding  the  conflict.  This  is 
then  displayed  to  the  controller,  who  specifies  the  parameters 
of  the  planned  action.  (For  example,  if  the  selected  planned 
action  were  a  "speed  change  for  resolution,"  the  controller 
would  decide  whether  to  increase  or  decrease  speed,  and  what 
the  target  speed  should  be.)  Upon  receipt  of  the  parameters. 
Conflict  Resolution  Planning  submits  the  new  planned  action  and 
the  existing  trajectory  to  the  Trajectory  Estimation  process 
for  remodeling.  The  new  trajectory  Is  then  probed  for  con¬ 
flicts  and  the  results  returned  to  the  resolution  process. 
These  results  are  then  displayed  to  the  controller  as  a  trial 
plan. 

As  with  any  trial  plan,  the  controller  may  approve  or  discard 
the  plan.  If  the  plan  Is  approved,  it  is  stored  as  the  current 
plan,  and  when  the  appropriate  time  is  reached,  a  reminder  will 
be  issued  to  the  controller,  specifying  the  action  to  be 
taken.  If  the  plan  Is  not  approved,  the  controller  has  the 
option  of  requesting  that  the  Conflict  Resolution  Planning 
function  try  another  solution  to  the  same  conflict,  or  may 
compose  his  own  resolution.  In  the  latter  case,  the  Conflict 
Resolution  Planning  function  is  not  involved.  However,  If  the 
controller  requests  that  a  different  resolution  be  generated  by 
the  system,  the  Conflict  Resolution  Planning  logic  must 
"remember"  which  solution  was  already  tried  and  discarded,  so 
as  not  to  select  the  same  resolution  again.  From  that  point 
on,  the  processing  is  the  same  as  that  already  described. 

5.2.3. 2  Metering  Planning 


In  AERA  2.01,  Metering  Planning  calculates  the  entire  metering 
plan  for  an  aircraft  at  one  time,  rather  than  planning  one 
advisory  at  a  time  and  waiting  for  controller  approval,  as  in 
the  previous  step.  After  the  Metering  Prediction  function  has 
determined  the  amount  of  delay  to  be  absorbed,  Metering  Planning 


generates  an  Initial  (trial)  plan  which  distributes  the  delay 
(which  planned  actions  to  use  where,  and  how  much  delay  each 
should  absorb).  After  generating  the  initial  parameters  for 
each  planned  action,  the  entire  plan  is  given  to  Trajectory 
Estimation  to  model,  and  the  resulting  trajectory  is  passed  to 
Problems  Prediction  for  probing.  The  results  of  the  probes  are 
returned  to  Metering  Planning,  which  may  then  have  to  refine 
the  plan  and  repeat  the  modeling  and  probing  process  until  a 
satisfactory  plan  is  achieved.  The  entire  plan  is  then 
presented  to  the  controller  for  approval,  and  upon  receipt  of 
approval,  the  trial  plan  is  made  current.  (If  the  controller 
does  not  wish  to  approve  the  plan,  he  may  alter  it  or  construct 
his  own  plan,  as  described  in  the  AERA  2.01  operational 
description  in  Section  5.3.2,  Multiple-Step  Metering.) 

5. 2. 3. 3  Execution  Stimuli 


The  Conflict  Resolution  Planning  function  is  activated 
following  a  conflict  probe  which  resulted  in  the  detection  of 
one  or  more  conflicts.  Following  the  display  to  the  controller 
of  a  candidate  planned  action,  the  function  waits  for  a 
response,  and  when  the  controller  does  respond.  Conflict 
Resolution  Planning  is  again  activated  to  complete  processing 
of  the  resolution.  Conflict  Resolution  Planning  might  also  be 
invoked  by  the  controller  to  generate  a  resolution  for  a 
potential  conflict  detected  by  the  Trial  Plan  Probe. 

The  stimuli  for  activation  of  Metering  Planning  are  the  same  as 
in  the  previous  step:  receipt  of  a  new  flight  plan  or  amend¬ 
ment  of  an  existing  plan  for  m  aircraft  In  a  metered  flow, 
modification  of  the  metering  goals ,  or  resynchronization  of  a 
metered  plan. 

5. 2. 3. 4  External  Interfaces 


The  results  of  the  initial  phase  of  the  resolution  processing 
(selection  of  the  resolution  maneuver)  are  presented  to  the 
controller,  and  the  controller  response  Is  returned  to  Conflict 
Resolution  Planning.  In  addition,  the  entire  metering  plan  for 
an  aircraft  is  displayed  to  the  controller,  and  the  controller 
response  returned  to  Metering  Planning. 

5. 2. 3. 5  Internal  Interfaces 


The  Conflict  Resolution  Planning  function  issues  requests  to 
the  Trajectory  Estimation  process  to  incorporate  Resolution 
Planned  Actions,  and  it  receives  the  results  of  the  conflict 
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probes  on  that  new  trajectory*  The  internal  interfaces  of 
Metering  Planning  are  unchanged  from  the  previous  step. 

5.2.4  Plan  Implements  t Ion 


The  Introduction  of  the  planning  enhancements  in  this  step  does 
not  affect  the  Conformance  Monitoring  function.  The  execution 
stimuli 9  external  and  internal  interfaces  remain  unchanged  from 
the  previous  step. 

The  Tactical  Execution  function  is  not  significantly  affected 
by  the  planning  enhancements;  its  processing  continues  as  in 
AERA  1.02,  although  goal-oriented  Resolution  Planned  Actions  as 
well  as  Altitude  Planned  Actions  are  now  modeled  and  processed 
by  TEX.  (Conformance  Monitoring  is  still  performed  only  for 
altitude  Planned  Actions.) 

There  are  no  changes  for  Tactical  Execution  in  the  execution 
stimuli  or  external  interfaces  from  the  previous  step. 

5.2.5  Tactical  Problem  Detection 


The  Separation  Assurance  Monitoring  and  Airspace  Violation 
Detection  functions  are  unchanged  by  any  of  the  new  features  of 
AERA  2.01. 

5.3  Operational  Description 

5.3.1  General  Resolution  Advisories 


5.3.1.1  Stimulus 


General  Resolution  Advisories  are  generated  for  conflict 
situations  that  have  been  identified  by  the  automated  probes  as 
candidates  for  resolution  and  displayed  to  the  controller. 

5.3. 1.2  Information  Displayed 

General  Resolution  Advisories  are  displayed  on  the  logical 
Alert  and  Resolution  display  along  with  the  message  notifying 
the  controller  of  the  conflict.  For  aircraft  conflicts,  the 
advisory  identifies  a  type  of  maneuver  that  would  be  effective 
in  resolving  the  conflict.  Examples  of  advisories  might  be 
"climb  aircraft  A"  or  "turn  aircraft  A  behind  aircraft  B."  The 
specifics  of  each  maneuver  (e.g.,  altitude,  speed,  heading)  are 
not  provided  by  the  system  in  the  advisory  but  are  left  for  the 
controller  to  specify. 


Por  conflicts  with  special  use  airspace ,  the  advisories 
identify  the  preferred  routes  or  SWAP  routes  for  avoiding  the 
airspace.  Maneuvers  required  for  the  aircraft  to  reach  the 
preferred  or  SWAP  routes  are  not  provided  in  the  advisory,  but 
are  left  for  the  controller  to  specify. 

5.3. 1.3  Controller's  Response 

When  a  conflict  is  detected,  the  controller's  responsibility  is 
to  devise  a  resolution  to  the  conflict,  using  either  one  of  the 
strategies  suggested  in  the  advisories  or  one  of  his  own  inven¬ 
tion. 

Since  an  advisory  presents  only  a  type  of  maneuver  without  the 
specific  parameters  required  to  amend  the  flight  plan  or  issue 
a  clearance,  if  the  controller  decides  to  consider  the  maneuver 
proposed  in  an  advisory,  he  must  specify  the  parameters  to  be 
used.  He  does  this  using  his  own  expertise  and  knowledge  of 
the  current  traffic  situation.  To  facilitate  the  entry  of  the 
parameters,  the  computer  automatically  presents  an  appropriate 
display  once  the  controller  indicates  which  advisory  he  wants 
to  consider.  Without  having  to  specify  the  entire  maneuver, 
the  controller  selects  the  particular  parameters  from  the 
display.  If  a  start -of -maneuver  point  can  be  identified  by 
Trajectory  Estimation  such  that  the  conflict  would  be  resolved 
by  the  maneuver,  a  Trial  Plan  Probe  Is  run  automatically  to 
ascertain  whether  any  additional  conflicts  would  be  created. 
The  results  of  the  Trial  Plan  Probe  are  presented  to  the 
controller.  If  the  controller  accepts  the  advisory,  the 
maneuver  is  inserted  into  the  aircraft's  trajectory,  and 
Controller  Reminder  messages  will  be  generated  to  notify  the 
controller  when  to  issue  the  clearance  to  the  aircraft. 

If  the  advisories  are  unacceptable  to  the  controller  he  may 
enter  his  own  resolution.  In  this  case  the  entire  maneuver 
must  be  entered — the  aircraft  ID,  the  type  of  maneuver,  and  the 
specific  parameters.  Since  the  resolution  is  still  goal- 
oriented,  the  optimal  start-of-maneuver  point  will  be  deter¬ 
mined  by  Trajectory  Estimation.  If  the  controller  gives  final 
approval  to  the  maneuver,  a  Controller  Reminder  message  will  be 
displayed  at  the  appropriate  time. 

5.3.2  Multiple-Step  Metering 

5. 3. 2.1  Stimulus 

As  in  previous  automation  packages,  Metering  Planning  deter¬ 
mines  which  aircraft  must  be  metered,  identifies  maneuvers  that 
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will  absorb  the  required  amount  of  delay,  and  displays  them  to 
the  controller  in  the  form  of  metering  advisories.  In  AERA 
2.01,  the  entire  metering  plan,  which  will  typically  consist  of 
multiple  steps,  is  generated  at  one  time  and  presented  to  the 
controller  for  approval.  After  the  controller  approves  the 
plan,  Controller  Reminder  messages  are  sent  when  it  is  time  to 
implement  each  step  of  the  plan. 

5. 3. 2. 2  Information  Displayed 

The  display  of  the  multiple-step  metering  plan  contains  the 
aircraft  to  be  metered,  the  meter  fix  or  boundary,  the  meter 
goal,  and,  for  all  steps,  the  specific  maneuvers  and  the 
amounts  of  delay  to  be  absorbed. 

5. 3. 2. 3  Controller^  Response 

The  controller  may  approve  all  or  part  of  a  metering  plan 
presented  by  Metering  Planning.  This  is  done  through  the 
interactive  display  on  which  there  will  be  a  specific  option 
for  approval  of  metering  plans.  If  the  plan  is  accepted  as  a 
whole,  it  is  immediately  incorporated  into  the  aircraft*s 
trajectory,  and  the  controller  will  receive  Controller  Reminder 
messages  at  the  appropriate  times  for  implementation  of  the 
individual  steps. 

If  the  controller  decides  to  accept  only  part  of  the  metering 
plan,  the  controller  specifies  the  steps  to  accept,  if  any. 
The  computer  will  display  the  amount  of  unabsorbed  delay .  The 
controller  may  request  an  additional  advisory  suggesting  a 
different  maneuver  to  absorb  the  remaining  delay,  or  may 
develop  his  own  plan.  Trajectory  Estimation  determines  start- 
of-maneuver  points  for  all  maneuvers,  and  if  the  controller 
accepts  any  part  of  the  plan,  the  trajectory  is  updated 
accordingly. 
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6.  AERA  2*02 


AERA  2*02,  the  second  stage  in  AERA  2,  reflects  enhancements  to 
the  computer-aided ,  problem-resolution  function  introduced  in 
AERA  2.01*  The  following  sections  discuss  Specific  Resolution 
Advisories,  Separation  Assurance  Monitoring,  transmission  of 
clearances  via  datalink,  and  several  other  enhancements. 

6 . 1  Enhancement  Fea tu res 

6.1.1  Specific  Resolution  Advisories 

From  experience  gained  in  previous  automation  packages,  the 
Conflict  Resolution  Planning  function  in  AERA  2.02  is  capable 
of  proposing  effective  specific  resolutions  to  detected 
conflict  situations.  The  resolution  advisories  contain  all  of 
the  specific  parameters  needed  to  issue  the  clearance  and  amend 
the  flight  plan.  With  the  advent  of  this  capability,  the 
controller’s  role  in  the  conflict  resolution  process  can  be 
reduced  to  final  arbiter,  with  the  tasks  of  generating 
effective  specific  resolutions  and  transmitting  the  associated 
clearances  to  the  pilot  via  datalink  performed  by  automation 

functions  (see  Section  6.1.2,  Uplink  of  Approved  Clearances). 

In  AERA  2.02,  Conflict  Resolution  Planning  is  designed  to 

suggest  several  specific  resolution  strategies  to  the 
controller  on  the  assumption  that  the  controller  is  best  able 
to  select  the  optimal  strategy.  By  AERA  2.03,  with  the 

experience  gained  in  this  automation  package,  the  automated 

resolution  generator  will  be  able  to  independently  select  the 
best  strategy  for  most  conflict  situations,  thus  freeing  the 
controller  to  concentrate  on  unusual  circumstances  in  which  his 
skills  are  required. 

6.1.2  Uplink  of  Approved  Clearances 

In  AERA  2.02,  the  expanded  data  link  capability  can  be  used  to 
automate  a  significant  activity  previously  performed  by  the 

controller,  transmitting  clearances  to  aircraft.  Clearances 

that  have  been  generated  by  one  of  the  automation  functions, 

such  as  metering  plans,  conflict  resolution  maneuvers,  control 
actions  implied  by  the  flight  plan,  or  planned  actions  that 
have  been  input  by  the  controller,  can  be  automatically 

uplinked  to  appropriately  equipped  aircraft  after  they  are 
approved  by  the  controller.  The  aircraft’s  trajectory  is 
updated  after  the  pilot  acknowledges  reception  of  the 
clearance,  which  is  done  via  datalink  or  voice. 
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The  automatic  handling  of  clearances  is  a  major  step  in  the 
transition  to  a  fully-automated  ATC  system.  The  controller's 
role  progresses  toward  that  of  expert  overseer,  in  which  he 
approves  decisions ,  maintains  awareness  of  actions  being  taken, 
but  relinquishes  routine  tasks  that  are  more  easily  automated, 

6,1,3  Separation  Assurance  Monitoring 

The  Conflict  Alert  function,  which  previously  predicted 
conflicts  between  radar  tracks  assuming  there  was  no  change  in 
direction  or  speed,  is  expanded  in  AERA  2.02  to  consider  flight 
plan  intend  as  well.  This  enhanced  function  is  termed 
Separation  Assurance  Monitoring  (SAM).  Though  for  safety 
reasons  there  is  always  a  need  for  an  independent  conflict- 
detection  capability  based  solely  on  radar  target  data,  the 
nuisance  value  of  the  false  consideration  of  alerts  generated 
by  this  process  is  expected  to  be  reduced  by  the  aircraft 
trajectories  which  represent  the  current  control  plan  for  the 
aircraft.  The  Separation  Assurance  Monitoring  function  uses 
estimates  of  future  aircraft  position  made  with  and  without 
knowledge  of  aircraft  intent  to  categorize  situations  in  which 
separation  may  be  lost. 

An  important  difference  between  this  new  prediction  method  and 
the  strategic  Flight  Plan  Conflict  Probe  is  that  SAM  uses  the 
aircraft's  current,  actual  position  as  the  starting  point  of 
the  prediction.  This  short-term  prediction  is  intended  to 
detect  near  term  violation  of  separation  criteria  that  will 
occur  if  the  aircraft  follow  their  expected  routes. 

Predictions  of  violations  made  by  the  two  methods  produce 
different  alerts  to  the  controller.  Since  the  trajectory-aided 
estimate  of  aircraft  position  reflects  the  most  current 
knowledge  of  the  intent  of  the  aircraft,  violations  predicted 
using  this  method  have  a  high  probability  of  occurring  and  are 
therefore  displayed  to  the  controller  in  a  high-level, 
attention-getting  alert.  Violations  predicted  on  the  basis  of 
radar  track  projections  are  false  alarms  more  often  than  is 
desirable,  •  but  their  detection  provides  a  useful  backup  warning 
system  and  is  displayed  in  low-level  alerts.  The  two  levels  of 
alerts  warn  the  controller  of  all  possible  problems  detected  by 
the  function  in  a  manner  that  helps  the  controller  evaluate  the 
severity  of  the  situation. 


6.1.4  Other  Enhancements 

The  Mmeterlng  Planning  function  will  have  been  tested  to  such 
an  extent  by  the  time  AERA  2.02  is  implemented  that  there  will 
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be  a  high  degree  of  confidence  that  the  metering  plan  proposed 
by  the  function  to  accomplish  the  metering  goal  will  be 
acceptable.  This  confidence  allows  the  plan  to  be  incorporated 
into  the  trajectory  as  soon  as  it  is  generated  rather  than 
after  controller  approval  is  obtained.  Early  inclusion  of  the 
metering  plan,  which  is  the  best  estimate  of  the  true  flight 
path  of  the  aircraft,  allows  the  trajectory  to  remain  current 
and  complete. 

The  capability  to  handle  Controller  Reminder  messages  is 
expanded  in  AERA  2.02  to  allow  the  controller  to  plan  any  type 
of  maneuver  for  future  implementation.  At  the  time  the 
maneuver  is  scheduled  to  be  executed,  the  controller  is 
notified  via  a  reminder  message. 

6.2  Functional  Description 


The  relationships  and  interfaces  between  the  AERA-related 
components  for  AERA  2.02  are  illustrated  in  Figure  6-1  and 
described  in  the  following  paragraphs. 

6.2.1  Trajectory  Estimation 

No  changes  or  enhancements  are  made  in  AERA  2.02  to  the 
Trajectory  Estimation  component.  Its  execution  stimuli  also 
remain  the  same:  It  is  activated  whenever  a  new  trajectory 
must  be  constructed  or  an  existing  one  modified.  Its  calling 
sequences  remain  unchanged,  although  new  uses  of  the  trajec¬ 
tories  appear  in  this  step  (for  example,  the  use  of  trajec¬ 
tories  in  the  Separation  Assurance  Monitoring  function).  The 
new  uses  do  not  actually  impact  the  internal  processing  of  this 
component,  and  so  will  be  discussed  in  the  paragraphs 
describing  the  using  components. 

6.2.2  Problems  Prediction 


The  only  change  to  this  component  is  the  upgrading  of  the  Long 
Range  Probe  function.  The  enhancements  to  this  function  may 
take  the  form,  of  automation  of  the  tasks  of  the  supervisor  (as 
described  in  the  section  on  AERA  1.02)  pertaining  to  the 
specification  of  high  density  areas  and  ATC-preferred  routes. 
Data  on  expected  and  historical  traffic  flows  will  be  evaluated 
by  the  automation  in  order  to  inform  the  controller  of  any 
anticipated  control  problems  beyond  the  range  of  the  Flight 
Plan  Conflict  Probe. 

The  execution  stimuli  would  remain  unchanged,  as  would  internal 
Interfaces.  External  Interfaces  may  be  modified  to  incorporate 
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possible  definition  (in  the  system  data  base)  of  traffic  flow 
patterns. 

No  changes  in  the  other  functions  of  the  Problems  Prediction 
component  occur  in  this  step. 


6.2.3  Solutions  Planning 


In  AERA  2.02,  the  two  constituents  of  the  Solutions  Planning 
component  remain  the  same  as  in  the  previous  step:  Conflict 
Resolution  Planning  and  Metering  Planning. 


6.2.3. 1  Conflict  Resolution  Planning 


The  first  processing  step,  as  in  AERA  2.01,  is  to  determine 
which  of  the  conflicts  in  the  encounter  data  base  require  the 
attention  of  the  Conflict  Resolution  Planning  function.  Once  a 
conflict  has  been  selected,  a  maneuver  category  and  an  initial 
selection  of  the  parameters  (or  constraints)  is  performed, 
based  upon  a  prioritized  set  of  rules.  The  end  result  is  a 
planned  action  description. 


This  description  of  the  planned  action  is  then  passed  to  the 
Trajectory  Estimation  function,  along  with  the  existing 
horizontal  route,  and  the  new  maneuver  Is  incorporated  as  a 
trial  plan.  The  resulting  trajectory  is  subjected  to  the  probe 
functions  of  the  Problems  Prediction  component,  and  the  results 
are  returned  to  Conflict  Resolution  Planning. 


The  probe  results  are  examined  to  determine  if  the  generated 
planned  action  accomplished  a  successful  resolution.  The 
criteria  for  success  Include  the  following  considerations: 

•  Was  the  conflict  under  consideration  resolved? 


•  In  removing  the  above-mentioned  conflict,  were  new  ones 
created?  If  so,  are  the  new  ones  "acceptable”  for  the 
purposes  of  this  resolution?  (A  new,  less  probable 
conflict  predicted  to  occur  in  thirty  minutes  may  be  an 
acceptable  trade-off  for  resolution  of  a  closer,  more 
probable  conflict.) 

If  problems  are  detected  with  that  particular  resolution,  the 
Conflict  Resolution  Planning  function  will  try  another 
resolution*  This  new  resolution  may  be  based  upon  a  new  type 
of  maneuver  altogether,  or  it  may  be  the  same  maneuver  with 
different  constraints.  For  example,  a  Resolution  Vector 
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planned  action  employing  a  left  turn  may  be  replaced  with  the 
same  planned  action  with  a  right  turn.  Conflict  Resolution 
Planning  must  keep  track  of  those  planned  actions  (and  their 
parameters)  which  have  previously  been  tried,  so  as  not  to 
repeat  resolutions  which  were  unsuccessful. 


Since  multiple  resolutions  are  presented  to  the  controller  in 
this  step,  the  above  processing  is  repeated  until  the  required 
number  of  successful  advisories  have  been  generated  (or,  if  the 
required  number  of  successful  advisories  cannot  be  found,  until 
all  reasonable  combinations  have  been  attempted). 

If  one  of  the  advisories  is  accepted  by  the  controller,  the 
plan  is  made  current  and  becomes  the  trajectory  used  to  probe 
against  other  aircraft.  If  the  controller  decides  to  specify  a 
new  advisory,  the  Conflict  Resolution  Planning  function  is  not 
involved,  since  the  controller  is  then  performing  the  planning 
function  himself.  The  other  planning  tools  such  as  Trial  Plan 
Probe  will  be  available,  however. 

6. 2. 3. 2  Metering  Planning 

The  basic  change  to  the  automatic  metering  process  is  that  the 
Metering  Planned  Actions  are  Incorporated  into  the  current  plan 
when  they  are  generated,  rather  than  only  after  controller 
approval  of  the  plan.  This  has  no  effect  on  the  generation  of 
the  metering  plan.  The  Incorporated  metering  plan  is  indicated 
to  the  controller  as  separate  Information,  as  a  message  or  on 
the  trajectory  display  for  that  aircraft. 

6. 2. 3. 3  Execution  Stimuli 

As  in  AEBA  2.01,  the  Conflict  Resolution  Planning  function  is 
activated  following  the  probes  of  the  Problems  Prediction 
component,  if  necessary  (i.e.,  if  any  conflicts  were  detected 
by  the  probes). 

There  is  no  change  in  the  activation  stimuli  for  Metering 
Planning . 

6. 2. 3. 4  Interfaces 

The  internal  interfaces  of  Conflict  Resolution  Planning  remain 
the  same,  and  the  external  interface  with  the  controller 
changes  slightly,  in  that  the  planning  interaction  of  AEKA  2.01 
is  removed. 


Similarly,  the  Internal  interfaces  of  Metering  Planning  remain 
unchanged,  but  the  external  interface  with  the  controller  (for 
approval  of  the  metering  plan)  is  deleted.  A  message  or  other 
method  to  inform  the  controller  about  the  metering  plan  is 
added. 

6.2.4  Plan  Implementation 

The  Conformance  Monitoring  function  does  not  have  any 
enhancements  or  modifications,  in  AERA  2.02;  its  execution 
stimuli  and  Interfaces,  both  internal  and  external,  remain 
unchanged  from  AERA  2.01. 

The  Tactical  Execution  function  monitors  for  adherence  to  the 
issued  clearance  and  the  intent  of  the  planned  action,  for  all 
types  of  planned  actions.  In  addition,  clearances  approved  by 
the  controller  are  datalinked  directly  to  the  aircraft  when 
appropriate. 

6. 2. 4.1  Execution  Stimuli 

No  change  in  execution  stimuli  occurs  for  this  step:  Tactical 
Execution  is  still  notified  by  the  Conformance  Monitoring 
function  when  it  is  time  to  monitor  a  planned  action  sequence, 
and  it  is  still  activated  when  new  track  data  is  available  for 
an  aircraft  being  monitored. 

6. 2. 4. 2  Interfaces 

An  Important  external  interface  new  to  this  step  is  the 
addition  of  the  datalink  to  the  aircraft.  Internal  interfaces 
remain  the  same  as  previous  steps. 


6.2.5  Tactical  Problem  Detection 

This  functional  area  consists  of  Separation  Assurance  Monitor 
and  Airspace  Violation  Detection,  enhanced  versions  of  Conflict 
Alert  and  MSAW  respectively. 

As  described  above,  an  important  change  in  the  Tactical  Problem 
Detection  philosophy  appears  in  AERA  2.02.  In  addition  to  the 
current  Conflict  Alert  and  MSAW  (where  the  present  position  of 
the  aircraft  is  projected  forward  with  assumed  constant 
velocity),  a  second  type  of  prediction  is  made.  The  new 
prediction  is  based  upon  the  current  position  of  the  aircraft 
and  any  expected  near  term  maneuvers. 


6. 2. 5.1  Execution  Stiaull 


There  is  no  change  In  the  stimulus  activating  Tactical  Problem 
Detection—the  component  is  activated  by  the  receipt  of  new 
tracking  data,  just  as  in  the  AERA  2.01  version. 

6. 2. 5. 2  Interfaces 


The  only  change  to  the  external  interfaces  is  the  presentation 
to  the  controller  of  alert  messages  (and  associated  resolution 
advisories)  resulting  from  trajectory-aided  predictions. 

The  change  in  the  internal  interfaces  consists  of  the  use  of 
the  strategic  trajectories  in  detecting  imminent  conflicts  with 
aircraft  or  designated  airspace  areas. 

6.3  Operational  Description 

6.3.1  Specific  Resolution  Advisories 

6. 3. 1.1  Stimulus 


Specific  resolution  advisories  are  generated  for  all  conflict 

situations  detected  by  the  automated  probes  and  displayed  to 

the  controller,  as  were  the  general  resolution  advisories  in 
AERA  2.01. 

6. 3. 1.2  Information  Displayed 

Specific  resolution  advisories,  which  are  displayed  on  the 

Alert  and  Resolution  logical  display  along  with  the 
notification  of  the  conflict,  contain  all  the  information 
needed  to  transmit  the  clearance  to  the  aircraft  and  amend  the 
flight  plan.  This  includes  the  aircraft  ID,  the  type  of 

maneuver  (altitude  change,  speed  change,  hold,  radar  vector, 
etc.),  a.  d  the  specific  parameters  relevant  to  the  particular 
maneuver  being  implemented.  A  limited  number  of  advisories 
(perhaps  three  or  four)  are  presented  to  the  controller.  If 
the  controller  accepts  one  of  the  advisories,  this  information 
can  be  reformatted  into  a  clearance  and  transmitted  directly  to 
the  aircraft  via  datalink. 

6.3. 1.3  Controller's  Response 

As  with  other  advisories,  the  controller  evaluates  the  specific 
resolution  advisories  presented  and  decides,  based  on  his 
expertise  and  knowledge  of  the  traffic  \  situation,  which,  if 
any,  of  the  advisories  to  accept.  An  option  on  the  interactive 
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display  allows  the  controller  to  accept  an  advisory  exactly  as 
it  was  presented*  If  the  aircraft  is  adequately  equipped  to 
receive  data  link  messages,  another  option  permits  the 
controller  to  have  the  associated  clearance  uplinked  directly 
to  the  aircraft.  In  the  optimal  situation,  the  controller  need 
only  select  these  two  options  to  implement  a  resolution 
strategy. 

If  the  controller  is  mostly  satisfied  with  one  of  the 
resolution  strategies  but  wants  to  modify  the  specific 
parameters,  the  capability  to  edit  the  displayed  resolution 
will  be  available.  For  Instance,  the  controller  may  agree  that 
an  altitude  change  Is  the  best  approach  for  resolving  the 
conflict,  but  may  disagree  with  the  specific  altitude 
suggested,  or  may  want  to  issue  the  change  to  the  other 
aircraft  involved.  To  facilitate  the  modification  process,  a 
limited  number  of  valid  entries  for  the  field  could  be 
presented  to  the  controller,  who  might  select  one  of  the 
entries  or  enter  a  different  value  via  the  keyboard.  After  the 
controller  has  modified  the  advisory  so  that  it  Is  acceptable, 
the  advisory  may  be  implemented  as  described  above. 

If  the  advisories  presented  are  unsatisfactory  to  the 
controller,  a  different  maneuver  and  specific  parameters  may  be 
specified  by  selecting  options  on  the  interactive  display.  A 
resolution  specified  in  this  way  is  still  goal-oriented,  and 
the  optimal  placement  of  the  maneuver  will  be  determined  by  the 
Trajectory  Estimation  function.  If  an  effective  resolution  can 
be  generated  using  the  selected  maneuver,  an  advisory 
containing  the  resolution  will  be  displayed,  and  the  controller 
can  then  implr^eat  it. 

6.3.2  Uplink  of  Approved  Clearances 

6 . 3 . 2 . 1  S  tlmulus 

When  the  controller  wants  to  issue  a  clearance,  regardless  of 
whether  it  has  been  strategically  or  tactically  planned,  the 
clearance  can  be  uplinked  to  the  aircraft  if  the  aircraft  is 
appropriately  equipped. 

6. 3. 2. 2  Information  Displayed 

Advisory  messages  that  suggest  maneuvers  for  aircraft  contain, 
besides  a  specific  maneuver,  an  indication  of  whether  or  not 
the  aircraft  has  the  equipment  required  to  receive  a  data  link 
clearance.  There  is  also  an  Indication  of  equipment  status 
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within  the  aircraft  data  for  each  flight.  On  the  interactive 
display,  there  is  an  option  which  can  be  selected  when  the 
aircraft  has  the  appropriate  equipment,  which  will  transmit  the 
clearance  via  data  link.  The  option  is  disabled  if  the 
aircraft  cannot  receive  a  data  link  message. 

6. 3. 2.3  Controller’s  Response 

The  controller  determines  whether  datallnk  can  be  used  by 
checking  the  equipment  indicators.  The  datalink  option  may  be 
selected  if  it  is  enabled,  which  will  cause  the  clearance  to  be 
transmitted  to  the  aircraft.  So  that  the  controller  can 
monitor  the  process,  an  indication  that  the  clearance  has  been 
transmitted  is  displayed.  The  system  waits  for  the  pilot  to 
acknowledge  the  clearance  before  Incorporating  the  amendment 
into  the  trajectory.  When  the  acknowledgment  has  been 

received,  the  controller  is  notified.  A  separate  verbal 
acknowledgment  from  the  pilot  may  also  be  required. 

6.3.3  Separation  Assurance  Monitoring 

6. 3. 3.1  Stimulus 

As  in  previous  versions,  a  Separation  Assurance  alert  is 
displayed  to  the  controller  when  the  predicted  positions  of  two 
aircraft  will  violate  separation  criteria  within  a  specified 
amount  of  time  (usually  approximately  two  minutes).  Predic¬ 
tions  of  violations  are  made  by  two  methods :  using  track  data 
only,  and  using  trajectories  supplemented  by  radar  position 
reports.  The  two  methods  generate  different  alerts  to  the 
controller. 

6. 3. 3. 2  Information  Displayed 

For  situations  in  which  the  trajectory-aided  position  estimates 
are  in  conflict,  the  alert  may  be  similar  to  the  current 
Conflict  Alert  in  which  the  data  blocks  flash.  The  controller 
can  display  track  vector  lines  to  help  visualize  the  location 
and  configuration  of  the  predicted  violation. 

The  low-level  alert  for  radar-based  predictions  is  displayed  in 
a  more  subtle  manner.  One  possible  format  for  the  alert  would 
be  for  the  projected  flight  paths  to  be  displayed  on  the  PVD, 
perhaps  in  a  distinguishing  color,  showing  the  location  of  the 
predicted  violation.  The  projections  would  be  a 
non-distracting  yet  Identifiable  alert  to  the  controller  of  a 
potential  problem. 
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As  in  today's  system,  the  controller  would  be  required  to 
evaluate  all  Separation  Assurance  situations  to  determine  If  a 
conflict  truly  exists  and  what  the  optimal  course  of  action 
Is .  If  the  controller  decides  the  situation  will  not  develop 
into  a  separation  violation,  the  alert  may  be  turned  off.  In 
which  case  either  the  data  blocks  will  stop  flashing  or  the 
projections  will  disappear.  If  the  situation  warrants  reso¬ 
lution,  the  controller  may  implement  the  maneuver  proposed  in 
the  Conflict  Resolution  Advisory  associated  with  the  alert,  or 
may  implement  his  own  strategy  for  resolution. 


AERA  2.03 


AERA  2.03  is  the  final  transition  package  before  complete 
automation.  All  functions  operate  as  if  they  were  automated 
except  that  controller  approval  is  required  before  the  machine- 
generated  resolutions  are  implemented.  Enhancements  In  the 
following  a re a 8  are  discussed  below:  single  global  resolution 
advisories,  resolutions  for  deviations  from  trajectories,  and 
clearances  datallnked  in  veto  mode* 

7 . 1  Enhancement  Features 


7.1.1  Single  Global  Resolution  Advisories 

In  AERA  2.03,  conflict  resolution  strategies  are  generated  by  a 
"super  planner"  that  has  knowledge  of  the  global  traffic 
picture,  including  the  goals  of  such  functions  as  Metering 

Planning  and  Conflict  Resolution  Planning.  This  perspective 

allows  the  planner  to  design  resolution  strategies  that  address 
multiple  goals  simultaneously.  The  single  optimal  resolution 
strategy  for  a  particular  situation  is  selected  and  presented 
for  controller  approval,  based  on  experience  gained  from  the 
multiple  resolution  advisories  generated  in  AERA  2.02.  There 
is  a  high  degree  of  confidence  that  the  controller,  who  must 
still  approve  all  resolutions  before  they  are  implemented,  will 
approve  the  proposed  strategy.  To  help  the  controller 

understand  the  reasoning  why  a  particular  strategy  was 
selected,  the  rationale  used  by  the  automation  function  is 

available  to  the  controller  on  request. 

The  integration  of  several  high-level  control  functions  that 
permits  the  display  of  a  single,  goal-oriented,  global 
resolution  strategy  is  one  of  the  last  major  steps  on  the  road 
to  full  automation.  In  previous  packages,  individual  functions 
were  automated,  but  the  controller  was  required  to  Integrate 
the  results  of  the  various  functions  in  order  to  develop  a 
cohesive  control  plan  for  the  sector.  Some  of  the  individual 
functions  were  designed  to  work  with  other  functions  (e.g., 
conflict-free  metering),  but  the  functions  were  not  capable  of 
resolving  more  than  one  goal  simultaneously,  even  concurrent 
problems  of  the  same  type  (e.g.,  an  aircraft  with  more  than  one 
conflict).  In  this  package,  the  automation  functions  are 
integrated  so  that  the  system  acts  as  if  it  were  fully 
automated,  except  that  controller  approval  is  still  required 
before  action  can  be  taken.  Removing  the  controller  from  the 
implementation  loop  will  be  the  final  step  to  full  automation 
in  AERA  3. 
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7.1*2  Resolutions  for  Deviations  from  Trajectories 

A  new  aid  is  introduced  in  AERA  2*03  that  provides  the 
controller  with  machine-generated  resolutions  to  detected 
deviations  from  the  aircraft’s  trajectory.  Whereas  in  previous 
packages  the  controller  was  informed  of  trajectory  deviations 
but  was  required  to  generate  his  own  resolutions ,  the  new  aid 
supplies  resolutions  that  allow  the  aircraft  to  meet  its 
planning  objectives  (metering,  conflict  resolution,  etc.)  in 
the  most  efficient  manner  from  its  present  position.  The 
automation  system  considers  planning  objectives,  neighboring 
aircraft  trajectories,  present  position  of  the  aircraft,  and 
the  global  control  plan  to  determine  the  optimal  strategy. 

When  an  aircraft  deviates  from  its  trajectory,  for  instance  due 
to  a  pilot-initiated  deviation  around  a  severe  weather  area,  it 
is  an  Important  and  sometimes  difficult  task  to  reunite  the 
aircraft’s  flight  path  with  the  computer-generated  trajectory. 
Since  the  trajectory  represents  the  current  plan  for  how  the 
aircraft  will  meet  all  of  its  planning  objectives,  deviations 
from  the  trajectory  may  imply  that  some  objectives  will  not  be 
met,  which  can  have  far-reaching  consequences  in  the  control 
plan  of  the  sector.  A  direct  return  to  the  trajectory  may  not 
always  be  the  optimal  solution  since  the  aircraft  may  not  be 
able  to  maneuver  back  to  the  trajectory  (e.g.,  if  it  is  already 
in  a  maneuver),  or  the  aircraft's  timing  may  be  off  such  that 
planning  objectives,  especially  metering,  may  be  missed,  or  a 
direct  route  to  the  next  fix  may  be  more  efficient.  In  such 
instances,  alternative  trajectories  must  be  generated  and 
possibly  the  objectives  redefined.  The  integration  of  the 
high-level  control  functions  in  AERA  2.03,  as  described  in 
Section  7.1.1,  makes  the  automation  system  well-equipped  to  do 
all  the  necessary  calculations. 

7.1.3  Clearance  Pa tal inked  in  Veto  Mode 

In  AERA  2.03,  the  use  of  datallnk  is  expanded  so  that  planned 
clearances  are  automatically  datallnked  to  the  aircraft  unless 
the  controller  explicitly  inhibits  their  transmission.  This 
capability  applies  to  all  planned  clearances:  conflict 

resolutions,  controller  planned  actions,  flight  plan-implied 
planned  actions,  metering  maneuvers,  outbound  handoffs,  etc. 
At  the  time  a  clearance  is  to  be  implemented,  a  message  is 
displayed  to  the  controller  that  is  similar  to  the  reminder 
messages  of  previous  packages.  The  message  notifies  the 
controller  that  unless  it  is  vetoed,  the  clearance  contained  in 
the  message  will  be  datallnked  to  the  aircraft  at  the 
appropriate  time.  The  controller  need  take  no  action  to  have 


the  clearance  Implemented  as  planned.  Only  under  exceptional 
circumstances  will  the  controller's  Intervention  be  required, 
In  which  case  he  can  expedite,  reject,  or  hold  any  planned 
clearance  (see  Section  7.3.3,  Data link.  Clearances  for  detailed 
descriptions  of  these  options). 

The  automatic  datalink  of  clearances  with  controller  veto  power 
is  only  one  step  away  from  the  complete  automation  of  the 
clearance  implementation  process  that  will  exist  In  AESA  3.  In 
AERA  2.03,  the  opportunity  for  controller  intervention  is  built 
into  the  implementation  process.  Though  it  need  not  impede 
implementation  if  everything  is  to  go  as  planned  (in  which  case 
the  controller  makes  no  overt  response  to  the  notification 
message),  the  controller  is  provided  the  opportunity  to 
intercede  if  the  situation  demands.  In  AERA  3,  clearance 
delivery  (as  well  as  other  control  functions)  is  performed 
entirely  by  the  automation  system,  with  the  controller 
monitoring  activities  at  his  discretion. 

7.2  Functional  Description 

The  relationships  and  interfaces  between  the  AERA-related 
components  for  AERA  2.03  are  illustrated  in  Figure  7-1  and 
described  in  the  following  paragraphs. 

7.2.1  Trajectory  Estimation 

Mo  new  changes  occur  in  this  component — its  functional 
capabilities,  execution  stimuli  and  interfaces  remain  the  same 
as  in  the  previous  step. 

7.2.2  Problems  Prediction 

None  of  the  functions  in  this  component  has  any  modifications 
or  enhancements  for  this  step.  All  interfaces  and  execution 
stimuli  remain  the  same  as  in  AERA  2.02. 


7.2.3  Solutions  Planning 

7. 2. 3.1  Conflict  Resolution  Planning 

In  AERA  2.03,  the  resolution  planning  gains  an  important 
enhancement,  that  of  global  perspective  of  conflict  resolu¬ 
tion.  This  broadening  of  scope  of  the  Conflict  Resolution 
Planning  function  is  an  attempt  to  give  the  automated  elements 
the  "big  picture"  that  the  human  controller  has.  Instead  of 
terminating  resolution  planning  with  the  first  successful 
resolution,  the  new  resolution  function  evaluates  several 


successful  solutions  and  makes  a  determination  of  the  "beat” 
alternative  resolution,  one  wftich  will  optimise  the  traffic 
situation  (and  possibly,  as  a  side  benefit,  reduce  controller 
workload)  for  a  given  area,  probably  the  Planning  Region.  The 
Conflict  Resolution  Planning  function  will  also  combine  or 
utilize  some  of  the  planning  elements  of  the  Metering  Planning 
function.  Perhaps  the  easiest  way  of  describing  the  scope  of 
this  improved  function  is  by  providing  a  comparison  with 
previous  Solutions  Planning  component  functions,  and  by 
illustrating  the  new  capabilities  with  an  example. 

In  the  previous  Conflict  Resolution  Planning  function,  a  set  of 
pre-defined  rules  was  used  to  determine  which  type  of  maneuver 
to  use,  and  what  parameter  values  to  initially  try.  If  that 
maneuver  was  successful,  there  was  no  reason  to  explore  further 
resolutions,  other  than  to  provide  the  controller  with  multiple 
successful  solutions  from  which  to  select.  If  an  aircraft  had 
several  conflicts  along  its  trajectory,  each  was  considered  and 
resolved  individually.  Since  metering  goals  were  not 
considered  directly  as  part  of  the  resolution  strategy,  it  was 
possible  that  a  maneuver  which  resolved  the  conflict  may  have 
also  interfered  with  the  metering  plan.  The  controller  had  to 
consider  that  fact  when  evaluating  the  resolutions  presented. 

In  AERA  2.03,  the  Conflict  Resolution  Planning  function 
examines  all  conflicts  detected  for  a  given  aircraft,  not  just 
the  first  one.  A  number  of  resolutions  are  generated  for  the 
first  conflict,  and  the  effect  of  each  resolution  on  the  other 
conflicts  of  that  aircraft  and  on  the  aircraft's  metering  goals 
are  then  evaluated.  The  solution  which  has  the  most  desirable 
overall  effect  on  the  aircraft's  plan  is  then  selected  for 
possible  incorporation  into  the  plan.  In  order  to  decide  which 
aircraft  in  a  conflict  should  be  the  "burdened"  aircraft  (i.e., 
the  one  which  is  given  the  maneuver),  it  may  be  necessary  for 
the  resolution  function  to  examine  candidate  resolutions  for 
both  aircraft  involved  in  the  conflict,  and  choose  the  maneuver 
which  has  the  most  beneficial  effect  on  the  overall  traffic 
situation. 

A  simple  example  of  the  use  of  the  Conflict  Resolution  Planning 
function  is  illustrated  in  Figure  7-2.  The  diagram  shows 
aircraft  A  proceeding  eastward  and  involved  in  two  conflicts, 
one  with  aircraft  B  and  another,  further  downstream,  with 
aircraft  C.  If  the  conflicts  are  examined  individually,  it  may 
appear  more  beneficial  to  move  B  in  order  to  solve  the  first 
conflict;  however,  this  would  require  another  maneuver  later  by 
either  A  or  C  to  resolve  the  second  conflict.  By  moving  air¬ 
craft  A  to  a  different  altitude  to  resolve  the  first  conflict, 
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the  second  conflict  will  also  be  eliminated  entirely.  Thus, 
one  maneuver  has  been  used  to  avoid  two  possible  conflicts. 
This  is  a  savings  not  only  to  the  pilots,  but  also  to  the  con¬ 
troller,  who  now  is  relieved  of  the  workload  associated  with 
resolution  of  that  second  conflict. 

This  example  is  an  extremely  simple  one;  more  complex  situa¬ 
tions,  especially  those  involving  metered  aircraft,  might  not 
have  such  a  clear  solution.  However,  it  does  Illustrate  the 
basic  concept  of  the  enhanced  AERA  2.03  Conflict  Resolution 
Planning  function. 

In  the  process  of  determining  the  "best"  resolution,  the 
planner  will  record  the  reasons  for  the  particular  solution 
which  was  selected.  When  presented  with  the  suggested 
resolution  advisory,  the  controller  may  request  to  see  tht 
justification  for  the  system-generated  resolution.  By  having 
access  to  this  information,  the  controller  may  better  evaluate 
alternatives . 

7. 2. 3. 1.1  Execution  Stimuli 


The  planning  functions,  Conflict  Resolution  Planning  and 
Metering  Planning,  are  both  initiated  by  the  same  stimuli  as  in 
previous  steps. 

7 . 2 . 3 . 1 . 2  Interfaces 


The  major  difference  in  the  interfaces  for  this  step  is  the 
interaction  between  Conflict  Resolution  Planning  and  Metering 
Planning.  The  Conflict  Resolution  Planning  function  may 
require  the  services  of  Metering  Planning,  or  at  least  be  aware 
of  the  metering  goals  for  any  given  aircraft. 

As  far  as  external  interfaces  are  concerned,  the  output  of  the 
resolution  function  may  now  be  augmented  with  justification  of 
the  generated  resolution,  upon  controller  request. 

7. 2. 3. 2  Deviation  Resolution  Planning 

The  Deviation  Resolution  Planning  function  is  introduced  in 
AERA  2.03  to  generate  resolution  advisories  that  will  direct 
deviating  aircraft  back  into  conformance  with  their  cleared 
plans,  or  generate  new  cleared  plans.  Resolutions  will  be 
formulated  for  deviations  in  altitude,  for  lateral  deviations, 
and  possibly  for  speed  deviations. 
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When  a  deviation  is  detected  by  the  Conformance  Monitoring 
function,  a  request  is  sent  to  Deviation  Resolution  Planning  to 
generate  a  candidate  planned  action  to  restore  the  aircraft  to 
its  cleared  plan.  Trajectory  Estimation  is  called  to  create  a 
trial  plan  incorporating  this  new  planned  action,  and  the 
resulting  plan  is  passed  to  the  probes  of  the  Problems 
Prediction  component. 

If  the  candidate  planned  action  generates  new  conflicts,  the 
parameters  of  the  planned  action  are  modified  or  it  is 
exchanged  for  another  planned  action,  and  the  modeling/probing 
process  is  repeated.  When  a  successful  plan  results,  the  new 
planned  action  is  displayed  to  the  controller  as  a  suggestion 
for  returning  the  deviating  aircraft  to  its  cleared  plan.  If 
the  controller  indicates  acceptance  of  the  new  planned  action, 
the  trial  plan  is  made  current. 

7. 2. 3. 2,1  Execution  Stimuli 


The  Deviation  Resolution  Planning  function  is  initiated  by  a 
request  from  Conformance  Monitoring  for  a  resolution  to  a 
detected  deviation  from  the  trajectory. 

7. 2. 3. 2, 2  Interfaces 


The  external  interfaces  involve  presentation  to  the  controller 
of  the  suggested  resolution.  The  internal  interfaces  include 
the  request  for  the  resolution  from  Conformance  Monitoring,  the 
request  for  modeling  and  probing  of  the  trial  plan,  and  the 
subsequent  return  of  the  results  of  the  probes. 

7.2.4  Plan  Implementation 

The  functions  in  this  area  are  enhanced  to  request  or  generate 
resolutions  to  detected  deviations.  Conformance  Monitoring 
detects  deviations  from  the  trajectory;  Tactical  Execution 
detects  deviations  from  the  goal  of  a  maneuver. 

7. 2. 4.1  Conformance  Monitoring 

In  AERA  2.03,  when  the  Conformance  Monitoring  function  detects 
a  lateral  or  horizontal  deviation,  in  addition  to  reporting  the 
deviation  to  the  controller,  the  function  passes  the 
information  to  the  Deviation  Resolution  Planning  function  so 
that  a  resolution  advisory  can  be  presented  to  the  controller. 
The  processing  within  Conformance  Monitoring  does  not  change  in 
this  step,  only  the  interfaces  change. 
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7.2.4, 1.1  Execution  Stimuli 


The  stimulus  for  initiating  the  Conformance  Monitoring  function 
is  not  changed  in  AERA  2.03. 

7 . 2 . 4 , 1 . 2  In  terf a  ces 


There  is  no  change  in  the  external  interfaces.  A  new  internal 
interface  is  the  request  from  Conformance  Monitoring  to 
Deviation  Resolution  Planning  to  generate  a  resolution  for  a 
detected  deviation. 

7.2.4. 2  Tactical  Execution 

When  a  deviation  from  the  intent  of  a  Planned  Action  is 

detected,  the  Tactical  Execution  function  generates  a 
resolution  advisory  which  will  put  the  aircraft  back  in 
conformance  with  the  planned  action. 

A  rather  simple  example  of  a  deviation  from  a  non-goal-oriented 
planned  action  would  be  the  case  of  an  aircraft  which  was  given 
a  clearance  to  reduce  speed  from  490  kts  to  400  kts.  The 
aircraft  reduces  to  440  kts  and  then  maintains  440.  Tactical 
Execution,  which  is  monitoring  the  aircraft,  detects  the  fact 
that  the  aircraft  fciaa  stopped  reducing  speed  and  generates  an 
advisory  which  would  accomplish  the  Intent  of  the  planned 
action.  (In  this  case,  that  may  be  as  simple  as  reiterating 

the  original  clearance  "Reduce  to  400  kts.”) 

The  development  of  clearances  which  compensate  for  deviations 
from  a  goal-oriented  planned  action  is  not  so  straight¬ 
forward.  For  example,  the  Tactical  Execution  component  detects 
that  an  aircraft  executing  a  Metered  Descent  Planned  Action  is 
not  using  the  expected  gradient,  and  in  fact,  will  not  now  be 
able  to  meet  the  metering  goal.  It  may  then  generate  a  clear¬ 
ance  (or  clearances)  to  accomplish  the  intent  of  the  original 
planned  actioa  (perhar  a  new  gradient  for  the  descent).  The 

clearance  is  displayed  to  the  controller  for  evaluation,  along 

with  the  identification  of  the  deviation. 

7. 2. 4. 2.1  Execution  Stimuli 


The  addition  of  resolution  capability  does  not  change  this 
component’s  initial  activation  stimuli. 
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7 ,2 .4.2.2  Interfaces 


The  change  to  the  external  Interfaces  involves  the  display  to 
the  controller  of  the  resolution  advisory,  along  with  the 
identification  of  the  deviation.  The  internal  interfaces  may 
also  change  in  that  Tactical  Execution  may  wish  to  use  the 
services  of  the  Trajectory  Estimation  and  Problems  Prediction 
components  in  generating  and  evaluating  candidate  resolutions. 

7.2.5  Tactical  Problem  Detection 


There  are  no  changes  to  the  Tactical  Problem  Detection 
functions  in  AERA  2.03.  The  execution  stimuli  and  int^ 'faces 
remain  the  same  as  in  the  previous  stage. 

7.2.6  Tactical  Problem  Resolution 


In  AERA  2.03,  the  resolution  advisories  generated  this 

component  are  coordinated  with  the  aircraft *s  trajeci  r  in 
order  to  generate  advisories  which  complement  the  immediate 
Intent  of  the  aircraft.  In  other  words,  an  aircraft  about  to 
begin  its  descent  to  an  airport  would  not  be  given  an  advisory 
to  climb  to  avoid  a  conflict.  (This  enhancement  may  just  as 
well  be  included  in  AERA  2.02  or  earlier.) 

7. 2 .6.1  Execution  Stimuli 


The  execution  stimulus  for  the  component  remains  unchanged:  It 
is  activated  each  time  the  Tactical  Problem  Detection  functions 
detect  a  tactical  control  problem. 

7 .2.6. 2  Interfaces 


The  major  difference  in  the  Interfaces  is  the  internal  use  of 
AERA  trajectories  in  the  formulation  of  resolution  advisories. 
The  external  Interface  with  the  controller  remains  unchanged. 

7.3  Operational  Description 

7.2.1  Resolution  Advisories 

7. 3. 1.1  Stimulus 


As  in  earlier  packages,  a  resolution  advisory  is  generated  in 
response  to  a  conflict  detected  by  one  of  the  automated  probes 
(Flight  Plan  Conflict  Probe  or  Airspace  Probe). 


7. 3. 1.2  Information  Displayed 


Resolution  advisories  in  AERA  2.03  contain  all  the  specifics  of 
the  resolution  strategy  needed  for  transmission  of  the  clear¬ 
ance  (s)  to  the  aircraft.  The  level  of  detail  is  identical  with 
that  of  resolution  advisories  presented  in  AERA  2.02. 

7. 3. 1.3  Controllers  Response 


The  expected  response  from  the  controller  on  receipt  of  an 
advisory  is  to  approve  the  resolution  as  presented  since  It  has 
been  carefully  examined  by  the  automation  and  determined  to  be 
an  optimal  solution  to  the  conflict.  To  approve  an  advisory, 
the  controller  would  be  required  to  make  a  minimum  of  entries 
into  the  computer,  perhaps  one  to  identify  and  approve/ 
disapprove  the  advisory  and  one  to  verify  approval. 

If  the  controller  is  curious  as  to  why  a  particular  strategy 
was  adopted,  the  rationale  used  by  the  automation  function  may 
be  displayed  by  selecting  an  option  on  the  interactive 
display.  A  textual  explanation  of  the  reasoning  behind  the 
selection  would  be  presented  on  the  interactive  display. 

The  proposed  resolution  may  be  modified  or  replaced  by  the 
controller,  in  which  case  a  comparative  analysis  on  the 
computer's  choice  and  the  controller's  selection  can  be 
performed  to  help  identify  where  the  plans  differ.  The  results 
of  the  analysis,  which  could  include  sucu  Information  as 
additional  fuel  burn  and  effect  on  metering  plans,  could  be 
displayed  on  the  interactive  display. 

7.3,2  Deviation  Resolution  Advisories 


7.3.2. 1  Stimulus 


A  deviation  resolution  advisory  is  generated  when  a  deviation 
is  detected  by  the  Conformance  Monitoring  function.  The 
advisory  is  displayed  along  with  the  deviation  alert. 

7. 3. 2. 2  Information  Displayed 


A  deviation  resolution  advisory  contains  Instructions  to  be 
given  to  an  aircraft  to  allow  it  to  be  reestablished  on  its 
trajectory.  These  instructions  may  or  may  not  constitute  a  new 
clearance  for  the  aircraft.  For  example,  if  an  aircraft  has 
drifted  off  to  the  right  of  its  route,  the  advisory  may  advise 
that  the  aircraft  ’’Turn  left  to  rejoin  route.”  This  type  of 
instruction  would  simply  be  communicated  to  the  pilot  without  a 


modification  to  the  flight  plan.  An  aircraft  that  was  cutting 
a  corner  on  its  route,  however,  may  cause  the  controller  to 
instruct  the  pilot  to  fly  direct  to  the  next  fix  rather  than 
turning  to  rejoin  the  cleared  route.  In  this  case,  controller 
acceptance  of  the  advisory  would  cause  the  flight  plan  to  be 
modified  and  the  trajectory  updated. 

7 .3. 2. 3  Controller’s  Response 


It  is  anticipated  that  the  controller  will  implement  the 
advisory  exactly  as  it  is  presented  since  it  contains  an 
effective  maneuver  for  either  rejoining  the  trajectory  or 
altering  the  trajectory  and  clearance  to  meet  stated  or  new 
objectives.  To  implement  the  advisory,  a  single  entry  on  the 
Interactive  display  may  be  required  from  the  controller.  The 
trajectory  and  flight  plan  will  be  updated  as  appropriate. 

Alternatively,  the  controller  can  implement  his  own  plans  for 
handling  the  deviation  by  simply  Instructing  the  aircraft  to 
return  to  its  route,  or  by  issuing  a  new  clearance  to  help 
reestablish  the  aircraft  on  its  route.  If  a  new  clearance  is 
issued,  the  trajectory  must  be  updated  appropriately. 

7.3.3  Data link  Clearances 


7. 3. 3.1  Stimulus 

At  the  appropriate  time  for  a  planned  clearance  to  be  issued  to 
the  aircraft,  as  determined  by  planned  actions  placed  on  an 
aircraft’s  trajectory,  a  message  is  displayed  to  the  controller 
Informing  the  controller  of  the  intended  control  action.  After 
a  specified  (system  parameter)  amount  of  time,  during  which  the 
controller  has  an  opportunity  to  veto  the  clearance,  the 
clearance  is  datalinked  to  the  aircraft. 

7. 3. 3. 2  Information  Displayed 

The  informatory  message  sent  to  the  controller  is  identical  to 
the  Controller  Reminder  message  sent  in  AERA  2.02.  Only  the 
controller ’8  response  differs.  The  message  contains  the 
details  of  the  planned  clearance,  such  as  the  aircraft  ID,  the 
complete  clearance,  and  the  reason  for  the  clearance  (metering, 
conflict  resolution,  etc.)  to  enable  the  controller  to  evaluate 
the  planned  action. 
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7.3.3* 3  Controller's  Response 

The  controller's  response  to  the  message  depends  on  the  action 
to  be  taken  with  respect  to  the  clearance. 

If  the  controller  wants  the  clearance  to  be  Implemented  as 
planned,  no  overt  response  Is  required.  This  Is  Interpreted  by 
the  automation  system  as  tacit  approval,  and  the  clearance  will 
be  datallnked  to  the  aircraft  at  the  appropriate  time,  which 
will  be  a  system  parameter  amount  of  time  after  the  message  was 
presented. 

If  the  controller  wants  the  clearance  implemented  immediately, 
an  "expedite"  option  is  available  on  the  Interactive  display 
which  causes  the  clearance  to  be  datallnked  without  delay. 

In  certain  circumstances,  the  controller  may  want  to  postpone 
implementation  of  a  clearance.  To  effect  this  a  "Hold"  option 
may  be  selected,  which  causes  the  clearance  to  be  held  and  not 
datallnked.  The  planned  action,  however,  remains  in  the 
trajectory  and  if  the  clearance  is  delayed  long  enough  that  the 
aircraft  deviates  from  the  expected  route  of  flight  (i.e.,  the 
trajectory),  deviation  alerts  will  be  sent  to  the  controller. 
To  avoid  this,  the  controller  should  amend  the  flight  plan  if 
the  clearance  is  to  be  delayed  a  significant  amount  of  time.  A 
clearance  placed  in  "hold"  mode  may  be  recalled  and  implemented 
at  a  later  point  in  time. 

Should  the  controller  decide  not  to  implement  a  planned 
clearance,  the  clearance  may  be  vetoed.  The  planned  action 
will  be  removed  from  the  trajectory  immediately. 
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AERA  3 


Full  automation  la  achieved  in  AERA  3,  which  la  the  end  product 
of  the  automation  process*  The  following  sections  give  a 
description  of  the  planning  and  control  process  under  AERA  3* 
A  more  complete  description  of  the  ATC  system  under  AERA  3  is 
available  in  the  ”AERA  3  Functional  Design  and  Performance 
Description  [12].” 

These  sections  describe  an  automation  system  in  which  the 
controller  becomes  an  optional  member  of  the  control  loop  and 
Is  freed  to  concentrate  on  monitoring  and  other  activities.  It 
is  impossible  at  this  time  to  specify  the  exact  form  that  such 
a  system  will  take.  The  optimum  degree  of  automation,  the  best 
division  of  responsibility  between  the  human  and  the  computer, 
will  depend  in  part  upon  the  design  of  the  AERA  functions  and 
on  operational  experience.  It  is  quite  possible  that  AERA  3 
also  will  consist  of  a  series  of  steps,  introducing  full 
automation  to  one  function  or  area  at  a  time.  This  section 
presents  a  fully-evolved  AERA  system. 

8.1  Enhancement  Features 


AERA  3  represents  the  culmination  of  all  the  automation  steps 
in  the  transition  packages.  The  automation  system  has 
progressed  from  detecting  possible  problem  areas  (AERA  1),  to 
devising  control  plans  for  particular  situations  (AERA  2),  to 
finally  implementing  the  control  plans  also  (AERA  3).  With 
each  new  package,  additional  control  functions  are  assigned  to 
the  automation  system,  relieving  the  controller  of  the  routine 
tasks  and  leaving  the  controller  to  apply  his  knowledge  and 
experience  to  decisions  requiring  his  expertise.  By  AERA  3, 
though  the  controller  is  still  responsible  for  the  overall 
control  plan,  it  is  expected  that  routine  control  actions  are 
fully  automated,  and  the  system  handles  most  functions  without 
controller  intervention. 

If  a  conflict  situation  is  detected  by  the  Problems  Prediction 
component,  a  resolution  is  generated  by  the  Conflict  Resolution 
Planning  function,  as  in  previous  packages.  Instead  of 
presenting  the  resolution  for  controller  approval,  however,  the 
system  automatically  Incorporates  the  maneuver  in  the 
trajectory  and  will  Implement  the  clearance  at  the  appropriate 
time.  The  experience  gained  in  previous  packages  allows  the 
resolution  function  to  reliably  select  the  optimal  strategy, 
eliminatiug  the  need  for  prior  controller  approval. 
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The  controller  will  receive  notification  of  the  conflict  and 
the  resolution  being  applied  so  that  he  can  aonitor  the 
situation  and  Intervene  If  a  change  to  the  control  plan  Is 
required.  Details  of  the  conflict  situation,  the  specific 
resolution,  and  the  reasoning  behind  the  resolution  are 
available  to  the  controller  to  facilitate  aonltorlng  activities. 

At  the  tine  the  clearance  Is  to  be  transmitted  to  the  aircraft, 
a  data link  message  Is  sent  automatically.  Aa  when  the 
resolution  was  Initially  generated,  the  controller  is  notified 
of  the  message  being  sent,  but  approval  (tacit  or  otherwise)  Is 
not  required  or  solicited.  Aircraft  acknowledgment  is  handled 
automatically  through  datallnk. 

In  the  conflict  resolution  process,  as  In  the  other  control 
tasks  In  AERA  3,  the  controller  can  monitor  the  activities  of 
the  automation  system,  intervening  only  If  a  change  is 
required,  or  can  attend  to  other  matters. 

No  enhancements  to  the  metering  function  are  implemented  In 
AERA  3.  The  metering  advisories  have  been  automatically 
incorporated  In  the  trajectory  since  AERA  2.02.  The  only 
change  in  AERA  3  Is  that  the  clearances  are  automatically 
datalinked  to  the  aircraft  without  prior,  explicit  controller 
approval . 

Machine-generated  resolutions  for  trajectory  deviations  are 
also  handled  automatically.  The  controller  receives  notifi¬ 
cation  of  the  situation,  the  resolution,  and  the  transmittal  of 
the  clearance,  as  with  conflict  resolutions,  for  monitoring 
purposes . 

8.2  Functional  Description 

In  AERA  3,  the  majority  of  the  planning  decisions  are  made 
automatically,  with  the  controller  having  the  option  of  being 
kept  apprised  of  the  decisions.  The  diagram  in  Figure  8-1 
shows  the  data  flows  and  Internal  Interfaces  between  the 
components.  .  While,  at  first  glance,  this  diagram  may  not 
appear  appreciably  different  from  that  of  the  previous  step, 
there  Is  a  very  Important  difference.  The  controller  is  still 
receiving  information  on  the  state  of  the  system,  but  many  of 
the  planning  decisions  are  being  made  Internally. 
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CLEARANCES  DAT  ALIN  ICED  ( AUTOHAT  I CALLY  ) 


No  enhance  neat  a  are  added  to  this  component  for  A  ERA  3.  The 
execution  stimuli  and  Interfaces  remain  unchanged  from  the 
previous  step. 

8.2.2  Problems  Prediction 

No  enhancements  are  added  to  this  component — the  Interfaces  and 
execution  stimuli  remain  the  same  as  in  AERA  2.03. 

8.2.3  Solutions  Planning 

A  very  significant  change  to  this  component  is  the  absence  of 
the  controller  from  routine  participation  in  the  approval  of 
advisories  for  resolution  of  strategically  detected  conflicts. 
The  single  resolution  generated  by  the  Conflict  Resolution 
Planning  function  Is  Incorporated  into  the  current  plan  as  soon 
as  It  Is  determined  that  it  does.  In  fact,  resolve  the  target 
conflict.  The  resolution  advisory  is  datallnked  directly  to 
the  aircraft,  without  relying  upon  the  controller  for 
approval.  (When  the  planned  action  is  Incorporated  Into  the 
current  plan.  It  will  be  detected  on  the  trajectory  by  the 
Conformance  Monitoring  function  and  sent  to  Tactical  Execution 
at  the  proper  time,  to  be  datallnked  to  the  aircraft.)  The 
controller  may  choose  to  be  notified  of  the  conflict  and  the 
datallnked  clearance. 


The  main  change  to  this  component  is  that  the  resolution 
advisories  generated  to  resolve  deviations  from  the  cleared 
plan  are  not  first  presented  to  the  controller  for  approval 
before  being  Incorporated  in  the  current  plan.  In  AERA  3,  the 
trial  plan  generated  to  evaluate  the  effect  of  a  candidate 
resolution  is  immediately  made  the  current  plan  when  it  is 
determined  that  it  successfully  "resolved"  the  deviation.  The 
clearances  are  datallnked  automatically  to  the  aircraft,  but 
the  controller  may  still  receive  notification  of  any  clearances 
sent  (if  he  wishes),  along  with  the  notice  of  the  deviations. 

8. 2. 3.1  Execution  Stimuli 

The  absence  of  the  controller  in  the  planning  process  does  not 
affect  the  reasons  for  initiation  of  the  Solutions  Planning 
component — its  execution  stimuli  are  unchanged  from  the 
previous  step. 


8. 2. 3. 2  Interfaces 


The  change  In  the  external  Interfaces  of  this  component  la  the 
reaoval  of  the  interaction  with  the  controller,  required  in 
previous  steps  to  obtain  approval  of  a  resolution  advisory.  No 
new  Internal  Interfaces  result  froa  changes  In  this  step. 

8.2.4  Plan  Implementation 

There  are  no  changes  to  the  Conforaance  Monitoring  function  in 
this  step.  The  resolution  advisories  generated  by  Tactical 
Execution  to  resolve  deviations  froa  the  intent  of  a  planned 
action  are  no  longer  sent  to  the  controller  for  approval  before 
being  incorporated  Into  the  current  plan.  Following 
incorporation  into  the  current  plan,  the  resolution  advisory  is 
data  linked  to  the  aircraft.  Notice  of  this  transaction  aay  be 
displayed  to  the  controller. 

8. 2. 4.1  Execution  Stlaull 


There  is  no  change  In  the  execution  stlaull  for  Tactical 
Execution  for  this  step. 

8. 2. 4. 2  Interfaces 


The  only  change  in  the  interfaces  with  Tactical  Execution  Is 
the  reaoval  of  the  controller  Interaction  for  approval  of 
resolution  advisories. 

8.2.5  Tactical  Problea  Detection 


No  changes  are  introduced  for  this  coaponent  in  AERA  3.  Its 
execution  stlaull  and  interfaces  reaain  the  same  as  in  the 
previous  step. 

8.2.6  Tactical  Problea  Resolution 

By  AERA  3,  the  Tactical  Problea  Resolution  coaponent  has  becoae 
an  Independent,  autoaated  conflict  resolver  which  acts  as  a 
backup  to  the  other  AERA  functions.  In  this  step,  If  both 
types  of  conflict  detection  (trajectory-aided  and  projection  of 
current  velocity)  are  triggered  simultaneously,  the  Tactical 
Problea  Detection  coaponent  will  evaluate  the  two  predictions 
and  their  associated  resolution  advisories,  and  deteralne  which 
resolution  to  use.  This  resolution  will  then  be  sent  directly 
to  the  aircraft  (although,  as  aentloned  for  other  coaponents  of 
AERA  3,  the  controller  aay  choose  to  see  the  advisories). 


8.2,6. 1  Execu t i on  St imul 1 


The  conditions  for  initiating  this  component  are  not  altered  by 
any  changes  for  this  step. 

8, 2. 6. 2  Interfaces 


For  AERA  3,  the  Tactical  Problem  Resolution  component  may  data- 
llnk  Conflict  Resolution  Advisories  directly  to  the  aircraft 
(as  opposed  to  only  displaying  them  to  the  controller).  This 
datalink  capability  is  a  new  external  Interface — there  are  no 
new  internal  interfaces. 

8.3  Operational  Description 

The  controller’s  interactions  with  the  automation  system  in 
AERA  3  can  be  grouped  into  two  functional  categories: 
monitoring  activities  and  intervention  in  the  control  plan  for 
an  aircraft.  The  majority  of  the  interactions  will  be  in  the 
first  category  as  the  controller  keeps  current  with  the  traffic 
situation  and  explores  the  control  actions  planned  for 
Individual  aircraft. 

Since  the  controller  no  longer  plays  an  active  role  in  the 
implementation  of  the  control  plan  but  is  still  responsible  for 
the  actions  taken,  it  is  critical  that  the  controller  be  able 
to  follow  the  control  activities  performed  by  the  automation 
system  so  that  the  controller  can  intervene  if  necessary  and 
make  Informed  control  decisions.  The  automation  system 
facilitates  the  controller’s  monitoring  activities  by 
displaying  messages  to  the  controller  which  describe  problems 
detected,  resolutions  planned,  and  clearances  Implemented. 
These  messages  are  for  Informational  purposes  only,  not 
requiring  any  specific  response  from  the  controller.  Should 
more  detailed  Information  on  any  particular  aspect  of  the 
traffic  picture  or  control  plan  be  desired,  this  information  is 
available  on  request. 

It  is  not  clear  at  this  time  what  level  of  detail  the 
controller  will  require  to  keep  up  to  date  with  the  control 
functions.  The  messages  presented  automatically  to  the 
controller  should  contain  the  majority  of  the  information 
normally  needed,  and  only  on  occasion  should  more  detailed  data 
have  to  be  requested.  The  optimal  format  of  the  messages  is 
also  currently  undefined.  The  format  used  may  or  may  not  be 
identical  to  the  formats  used  in  previous  packages,  but  will  be 
designed  to  optimize  the  process  of  keeping  the  controller 
aware  of  all  control  activities  performed. 


The  second  type  of  Interaction  with  the  autoaatlon  ays tea 
occurs  when  the  controller  determines,  based  on  aonltorlng 
activities,  that  intervention  In  the  planned  control  actions 
for  an  aircraft  is  necessary.  Since  the  controller  Is 
ultiaately  responsible  for  the  control  plan,  he  aay  at  any  tiae 
change,  add  to,  or  override  the  machine-generated  plan.  The 
procedures  for  intervention  are  optlalsed  for  efficiency  and 
simplicity  of  use,  and  aay  or  aay  not  be  identical  to  previous 
procedures . 


CONCLUSION 


This  report  has  presented  a  series  of  descriptions  of  the  AESA 
packages,  as  currently  envisioned.  Both  operational  and 
functional  characteristics  have  been  discussed:  what  the 
functions  are  intended  to  do,  and  how  they  are  expected  to 
interact  with  the  controller  and  other  ATC  f- actions. 

Each  package  was  described  in  detail,  in  order  to  cover  all 
relevant  aspects  to  the  extent  possible.  However,  an  attempt 
was  also  made  to  present  the  evolutionary  context  for  the 
overall  development  of  AREA.  Each  package  is  planned  to 
provide  a  foundation  for  later  enhancements,  all  leading  toward 
the  goal  of  full  ATC  automation. 

This  document  is  not  intended  to  be  a  formal  description  of  a 
fully  developed  system.  There  are  many  unresolved  issues 
remaining,  and  much  research  and  analysis  to  be  done.  This 
material.  Instead,  outlines  a  line  of  development  to  pursue. 
The  publication  of  this  material  is  appropriate  at  this  time, 
to  document  the  current  design  of  AERA,  to  provide  Information 
useful  to  the  design  of  the  AAS,  and  to  stimulate  discussion. 

The  descriptions  of  the  individual  packages  will  need  to  be 
expanded,  as  has  been  done  already  for  AERA  1.01  [5],  and 
revised  as  more  is  learned  about  technical  and  operational 
details.  In  addition,  this  overview  of  the  AERA  packages  will 
need  to  be  revised.  Changes  to  these  descriptions  are  not  only 
expected,  they  are  the  desired  result  of  documenting  current 
thinking . 
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